Language backends other than C#
Closed this issue · 7 comments
It would be cool to be able to generate code for other languages than C#, such as maybe F#, Visual Basic .NET, IronPython, IronRuby, etc.
Yeah, sadly most of the languages work very different so it would require a lot of work (would have to break out a lot of code, move things that are language specific etc).
The closest one would be Visual Basic as Roslyn handle both that and C# but I haven't look into it.
Is this feasible? Any (rough?) draft?
Would this improve the architecture of the library by separating concerns, by separating interfaces from implementations or would it just make the library more complex?
Perhaps the strategy pattern could be used?
The framework was not built with this in mind so it would of course require a lot of changes. For example all generate and statement classes returns Roslyn objects which would not work if we started to support other languages.
Instead we would had to create our own classes/interfaces that we return and extends on.
We would also have to change a lot of the overall design. For example the Statement class is static for simplicity but I don't think it would work that well with multiple languages.
So it's feasible but it would take a lot of work and thinking.
But my understanding is that Roslyn supports both C# and Visual Basic .NET.
Yeah but they use classes from different namespaces so I think we still would have to work with our own objects (sadly). Or we would have to go to the absolut bottom of the chain.
For example:
The ClassBuilder currently return a TypeDeclarationSyntax object when calling Build() but this is a C# specific class. For Visual Basic we would have to return TypeBlockSyntax. But we could also fix this by returning a SyntaxNode instead as we see here:
Inheritance
Object -> SyntaxNode -> VisualBasicSyntaxNode -> StatementSyntax -> DeclarationStatementSyntax ->TypeBlockSyntax -> ClassBlockSyntax
Inheritance
Object -> SyntaxNode -> CSharpSyntaxNode -> MemberDeclarationSyntax -> BaseTypeDeclarationSyntax -> TypeDeclarationSyntax -> ClassDeclarationSyntax
But I'm not sure if I like that either as we have to do that in all generator classes too.
In my opinion, lets focus on one thing and do it very well. The more things you do, the less 'good' each thing is. If the goal is to also add VB.net, then an extension package should be created outside of the core package, imho.
Agreeing with @jeffward01 and we will focus on C# for now. So will close this issue for now.