tradeoffs between generating base class/mixin or subclass

[sigmundch]

We've been debating between a few ideas on what to do in terms of codegen:

• generate a base-class/mixin (what the current example in this package does)
• generate a subclass

For example, the first approach the user writes a class with private members, and source-gen will create public members that are observable:

// written by the user:
class Model extends _Model {
  @observable int _i;
  @observable int _j => i + 1; // note, need to refer to public name `i` which is autogenerated
}

// generated:
class _Model {
  int get i => ...;
  int get j => ...;
}

The second approach has the user write public members in a private class, and the tool generates the public copy of that class:

// written by the user:
class _Model {
  @observable int i;
  @observable int j => i + 1;

  static foo();
}

// generated:
class Model extends _Model {
  int get i => ... super.i ...;
  int get j => ... super.j ...;

  // need to redirect static methods & constructors
  static foo() => _Model.foo(); 
}

Both approaches have a problem: we need to generate pieces that become part of the public API of the library, and the user needs to be aware of this.

In the former, the observable properties are public names, so the developer needs to be careful to use them everywhere (and not the private properties he initially defined). For example, see that the getter for _j is accessing the public name i, and not _i, otherwise we won't be able to determine that a change in i should issue a change notification on j.

In the latter approach, the problem is that the public class name is generated. So it may not be as intuitive that you shouldn't do new _Model. There is also some additional complexity that static methods and constructors on that class need to be redirected by the public class too.

In both cases jump-to-definition has some results that are not optimal: jump to the class definition works great in the first approach, but not on the second (you get the generated definition, which is not likely the definition you want to see). Conversely, jump to the field/property definition has the same problem in the first approach but not the first.

Documentation might be in the wrong place too. We would need to copy docs to the public members (approach #1) or the public generated class (approach #2).