msggen: introduce chain of responsibility pattern to make msggen extensible

[vincenzopalazzo]

This abstraction was easy beceuse @cdecker make a great work

So, when mssgen will be released like a library, the user can create their own generator that extends IGenerator, and put it inside the following configuration

def gen_dotnet(generator_chain: GeneratorChain):
    fname = "<your path>"
    dest = open(fname, "w")
    generator_chain.add_generator(DotnetGenerator(dest))

if __name__ == "__main__":
  service = load_jsonrpc_service(schema_dir="<json schema path>")
  generator_chain = GeneratorChain()
  gen_dotnet(generator_chain, meta)
  generator_chain.generate(service)

Pro:

• We don't need to trust the user to push code that works in the own repository, but now the user can generate and test the code in the repository that depended on the model that is generated;
• The user can export this generator like the library and make available the work as a python package.
• The user is not coupled with a specific library if any are used, but if there is something wrong for a user in the generator implementation he can reimplement the own.

Cons:

• a new package to maintain, but it is better that maintains X programming language with its own release process

[cdecker]

I'm not quite sure what you're trying to achieve here, if we release msggen as a library, then it is trivial to extend the existing classes, and write a tiny entrypoint that loads and generates. There is no need to wire everything into a single top-level executable which seems to be what you're doing here (and I have done myself as a shorthand).

Let's keep the refactoring and the creation of a top-level interface, and drop the plugin-like system of adding a generator to a set of generators that are to be executed as a block. That is also much more in line with the Makefile semantics.

[vincenzopalazzo]

I'm not quite sure what you're trying to achieve here, if we release msggen as a library, then it is trivial to extend the existing classes, and write a tiny entrypoint that loads and generates. There is no need to wire everything into a single top-level executable which seems to be what you're doing here (and I have done myself as a shorthand).

The chain of responsibility IMHO is a good addition to include in the library, because can be some cases where we can dependencies between steps.

This pattern can make the code cleaner to read and write imho. However, the same solution is achieved with the hardcoded inside the python script from the user!

[cdecker]

I see, the generator chain threw me off, as it looked like we'd end up creating a single huge chain that'd add all the generators to a single entry-point, whereas you plan to build a chain for each entry-point which can then live in various different repos, independently of this repo.

Seems quite alright, thanks for the cleanup along the way. I'm not exactly convinced that the chain of responsibility pattern is what we want here (or if it is even achieved by the code, since every message goes through every generator, and isn't handled by the first matching generator), but it doesn't add much complexity and can serve as a grouping of logically correlated generators.

ACK 79c3df7