AArnott / CodeGeneration.Roslyn

Assists in performing Roslyn-based code generation during a build.
Microsoft Public License
408 stars 59 forks source link

Rich generators #80

Closed amis92 closed 6 years ago

amis92 commented 6 years ago

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:

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 commented 6 years ago

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

amis92 commented 6 years ago

@AArnott ping? What are your thoughts? #Closed

amis92 commented 6 years ago

@AArnott pinging again. Any reaction? #Closed

amis92 commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

@AArnott pinging for review :) #Closed

AArnott commented 6 years ago

Sorry... looking now.. #Resolved

AArnott commented 6 years ago

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 commented 6 years ago

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. :)