Alternative simple stable classes

[Kamirus]

I have an idea that I'd like to discuss as an alternative to the 'stable functions PR'.

Why: What are the issues with the PR:

• TODO

Goals

• I guess the goal is to remove transient keyword and have all things stable. While this is a nice simplification. I'm not sure with the current PR this is worth complicating other aspects of developing in Motoko.
• Instead of completely removing transient we can develop a partial solution that allows us to compile more cases as stable. I have an idea to support stable definitions of classes in a restricted context, but the one that appears common in practice

Idea

1. Check out the prototype on ICP Ninja that defines a library with a class where the state is separated out. In the app-code the class can be defined as transient but it does not mean that its state is discarded on each upgrade. The state of the class is explicitly stored in the app-code and made persistent over upgrades.
2. This pattern is easy to follow but requires boilerplate code (it also does not encapsulate the state of the Lib, the app-code has full access to it and must manage it)

Stable classes as (stable data + transient funcs)

The idea is to compile classes by separating out their stable data and persisting only that, and hiding the transient nature of the object with funcs.
Stable classes would need to be desugared to classes with no internal state (no internal fields), where state is passed via the constructor.
Why it might work?

1. Classes with no fields and no constructor parameters can be safely recreated on each upgrade (no data to loose)
2. Classes with no fields can be made stable by recreating the class-object Cls(args) on each upgrade when args are persistently stored as an actor field. This means that we can desugar let c = Cls(args) to

let c@args = args;
let transient c = Cls(c@args)

What about args that have functions inside, e.g. args = (arg, Int.compare)? We don't need to persist Int.compare. We should decompose args into a set of stable fields:

let c@arg = arg;
let transient c = Cls(c@arg, Int.compare)

How to support more than static functions like Int.compare? We cannot support arbitrary types, e.g. [var (Int -> Int)]
Can we simply persist as much of the args as possible and leave others transient?
How would users know which parts are persisted and which not?

I guess this is tricky to communicate. However, when trying to provide a migration function the compiler would know the required type. User would only need to inspect the inferred type.

3. Classes with fields (or at least fields with mutable references) would not be supported.

Restrictions:

• This only considers stable classes to be used in field definitions of an actor, not in arbitrary contexts. E.g. creating a class-object in a function and then calling this function to create a stable class field won't be possible with this design.
  This means that classes are not considered stable, it only means that some classes can be transformed to stable code...
• The idea is only to automate the handling of classes that have the persistent data separated out from the funcs.

Migrations

• On explicit migration: class-values would need to be migrated, but in the migration function we must simply migrate only their state. Because internally we want to persist only the data, recreating the object with funcs.
• When migrating let c = Cls(args) to a new let c' = Cls'(args')
  User would need to translate the c record like { arg1; ...; argN } (with names taken from the Cls) to a record c' with its stable state.

[crusso]

This is pretty much the pattern that OrderedMap is using, and it also works for mutable state.

This reminds me of the small orderedset examples I worked out here: functional, imperative and class based.

https://icp.ninja/i?s=wL940