Rich generators

[amis92]

It's just an initial concept draft to start up a discussion

I've got an idea for a big enhancement: a feature that would enable many more scenarios for code generation in this framework, namely:

• add ability to completely control ancestry of generated code (namespace, ancestor partials) (#40)
• add top-level (compilation unit) usings (#30)
• add top-level extern aliases
• add top-level attributes ([assembly: Xyz])

My proposal adds a new interface that has a method with the same parameter list as current ICodeGenerator.GenerateAsync, but returns Task<RichGenerationResult> which contains four syntax lists: Members, Usings, Externs and AttributeLists that get merged with those created by previous generators and then are added to the generated compilation unit.

There are no tests currently, but I will add them, if the design would be accepted.

[amis92]

@AArnott I've rebased onto master after merging #79. What do you think of the proposed enhancements? #Closed

[amis92]

@AArnott ping? What are your thoughts? #Closed

[amis92]

@AArnott pinging again. Any reaction? #Closed

[amis92]

@AArnott I've added tests, done some refactors and bumped lang ver to 7.3 as requested.

I think I'm done here. What's your take on this? #Closed

[amis92]

One major refactor I should maybe explain is the move of wrapping-member-in-ancestor logic; I've moved it into a separate nested class which I've named EnrichingCodeGeneratorProxy. It essentially hides that logic behind IRichCodeGenerator interface.

So the processing is now more streamlined: non-rich generators are now wrapped into Proxy class, and only the Rich generation is called in the TransformAsync foreach loop.

One other thing I've been uncertain, is: should the TransformationContext and RichGenerationResult have public constructors? Maybe we could offer some factory methods instead. That way we could reserve space for future changes/additions without breaking existing code.

[amis92]

@AArnott pinging for review :) #Closed

[AArnott]

Sorry... looking now.. #Resolved

[AArnott]

I don't see how a factory method will make it more future-proof than a ctor. We would presumably add more of either one as we add members. However, the fact that you're already using default parameters on the first "overload" may make it tricky to add more overloads with default parameters later. I'll leave more comments in the relevant files.

---

In reply to: 413479597 [](ancestors = 413479597)

[amis92]

I'm glad I could help! All the comments were valid and I see the point. I've got a little carried away on that immutability bandwagon. :)