reduce limitations

[Andersmholmgren]

The limitations listed in the transformation doco effectively render it useless for me. I very often have multiple constructors, use inheritance and have mostly immutable classes where the constructors contain some logic.

Are there any plans to improve this? In particular, provide a way to specify the constructors to use. One way is via annotations. Another would be to allow defaults to be specified. e.g. default to always calling the unnamed constructor, or a constructor called say 'build'.

FYI I do support such features in shelf_bind and it wasn't overly complex from memory, but that was with mirrors - I haven't tried transformers yet - maybe that is trickier?

Limitations
Note that this is quite limited. It does not handle inheritance at all. If constructors have parameters which are not of the form "this.field", those will always be passed as null. It will always use the constructor with the fewest parameters. It does handle getter/setter pairs and getters or fields which correspond to constructor parameters. It will probably not work with part files, and it expects all the classes that will be serialized to be listed in those files.

[alan-knight]

There are no plans at the moment, but pull requests are welcomed :-) This is mostly a proof of concept/suitable for very simple cases. It would be perfectly reasonable to make something based on it that understands more about your conventions. But it would also be nice to improve this one.

The point of the transformer is to avoid using mirrors. If you're willing to use mirrors, the BasicRule does provide quite a bit more ability to specify the constructor to use, the parameters, and so on. But you'd have to do the MirrorsUsed annotations.

Even in the transformer case, using the analyzer it ought to be possible to get enough information to do fairly arbitrary things, the issue is how complicated it is to specify, and which cases to handle. The rules are not that difficult to write by hand, so at some point writing sufficiently general annotations is not that much better than writing the line of code that calls the constructor directly.

If you can use something opinionated/project-specific the annotation approach could be a lot simpler. e.g. you could do

class Foo {
@UseInConstructor
var thing;
var otherThing;
Foo(this.thing);
}

And you're just left with figuring out the order in which to put things in the constructor, or else enforcing that the name in the constructor must agree with the variable name.

Inheritance with constructor parameters is particularly tricky to do in general, because you could have cases like
Foo(this.a, b, c, this.d, e) : super(c, e, namedThing: b);