Add a note about not importable annotations

[natebosch]

The build systems run on the Dart VM only, so there are limitations on
what imports can be used by builders. Add documentation describing how
to work around this limitation by overriding the TypeChecker with
something other than fromRuntime.

[jakemac53]

Should we just provide a GeneratorForMatchingAnnotation which takes a TypeChecker?

[kevmoo]

Should we just provide a GeneratorForMatchingAnnotation which takes a TypeChecker?

Just as a factory even, would be great. A follow-up is good here.

[natebosch]

Should we just provide a GeneratorForMatchingAnnotation which takes a TypeChecker?

Just as a factory even, would be great. A follow-up is good here.

The existing design imposes an extends already - you are intended to override generateForAnnotatedElement.

It would be nice to change that and allow composition but 🤷‍♂️

Given the current design, I think @override fits. WDYT?

[jakemac53]

Given the current design, I think @override fits. WDYT?

Ya the design I would envision is making a base class that just takes a type checker, and then the existing class would just extend that to make the type checker for you.

I wouldn't change anything about how it works generally, just which class you extend would change (and what you pass to the super constructor)

[natebosch]

which class you extend would change (and what you pass to the super constructor)

Adding another class to the public API would increase the surface area of the package and IMO make things harder to find.

[jakemac53]

Adding another class to the public API would increase the surface area of the package and IMO make things harder to find.

🤷‍♂️ I don't really agree, I think its significantly better than doing the whole GeneratorForAnnotation<void> thing and then overriding the type checker. Overriding the type checker in that way is definitely a bit funky, and you are relying essentially on how that thing is being used internally in the super class...

[natebosch]

I'm not able to find a design I like here with another class (especially because I can't think of a nice name).

With a breaking change I could imagine something different, maybe where we drop the generic and you need a constructor when forwards to super.forType(someType) or super.forTypeChecker(someTypeChecker). If we're going with a breaking change we may as well drop the need for extends entirely though...

[kevmoo]

@natebosch – thoughts on this?

[kevmoo]

Uh...this is old @natebosch

[natebosch]

@jakemac53 - do you think this is worth landing as is?

[jakemac53]

Suggested change

>>>>>>> master

[jakemac53]

I still really don't like the GeneratorForAnnotation<void> suggestion personally. Should we instead just tell people to split up their annotation libraries so they don't have those imports?

[natebosch]

Should we instead just tell people to split up their annotation libraries so they don't have those imports?

I don't know if that is always feasible - some annotations could use dart:ui classes as arguments.

[natebosch]

@jakemac53 - is this implementation of GeneratorForMatchingAnnotation match what you were thinking?