[pigeon] Relocates generator classes and updates imports

[tarrinneal]

Relocates generator classes and updates imports. Initial set up for flutter/flutter#117416

[stuartmorgan]

Initial restricting LGTM. (Eventually we'll want to revisit things like C++ and ObjC being two generators, and probably the sink creation location.)

[stuartmorgan]

We should ideally move these two utility methods to a utility file, and find somewhere for the other things to live, so we don't have circular includes. Than can be done later though.

[gaaclarke]

The reason that the Generator was in the place it was previously is that it was keeping PigeonOptions out of the generator files. The idea being that the generators are cleaner/safer/easier-to-maintain if they only have access to the options designated for them instead of giving them every single option. The idea of the Generator was more of an adapter of the public functions in the generator files which were the actual generators.

If you wanted to retain that organization it's going to be more difficult if you move the Generator implementations to the generator files. You'll have to make Generator generic:

abstract class Generator<T> {
  void generate(StringSink sink, T options, Root root);
  List<Error> validate(T options, Root root);
}

Then when you store adapters between PigeonOptions and the input that the Generator needs where you store all your generators.

/// Adapts a Generator to PigeonOptions
class GeneratorAdapter {
  GeneratorAdapter({this.generate, this.shouldGenerate, this.validate});
  void Function(StringSink sink, PigeonOptions options, Root root) generate;
  IOSink? Function(PigeonOptions options) shouldGenerate;
  List<Error> Function(PigeonOptions options, Root root) validate;
}

var generator = Generator();
generators.add(GeneratorAdapter(
  GeneratorAdapter(
    generate:(sink, options, root) => generator.generate(sink, options.fooOptions, root),
    shouldGenerate:(options) => _openSink(options.fooOut),
    validate:(options, root) => generator.validate(options.fooOptions, root)));

The benefits being:

1. it makes the Generator API more simple
2. it separates the idea of generating code and adapting it to the PigeonOptions format
3. it keeps PigeonOptions out of the generator files

How do you like that?

[gaaclarke]

Sonofabitch, late comment. For architecture questions can you guys touch base first. I didn't really have an opportunity to react to this.

[stuartmorgan]

We can revert+retract if this is an issue. I didn't expect putting the generator classes in the generator files to be controversial.

The idea of the Generator was more of an adapter of the public functions in the generator files which were the actual generators.

This is why naming is important; I didn't expect that in a package where the most important conceptual thing are generators that the Generator class wasn't intended to represent a generator.

[gaaclarke]

Yea, it should have been "_Generator" but was made public to help with testing. We don't need to retract. I think separating the adapter and the generator makes everything tidier and easier to maintain but we can do that in a different PR. I think having a Generator abstract class that people follow along in the generator files makes it a bit easier conceptually instead of having loose functions, so that is an improvement.

[gaaclarke]

I think there is more to be said here if we want to make this public =)