For me it just seems you define the 'concern' of CodeGenerator MUCH
different than I do. IMHO this is just a helper class that eleminates
unneccessary code duplication. If you want to start from scratch - No
problem. Just implement the ICodeGenerator interface in whatever class you
like. There is NO NEED to use this class to do code generation.
Also I don't know what your whole C# thingy is: MS probably choose to
implement methods which seemed as they may be used by several different
languages to avoid code duplication. If you look at something like:
protected virtual void OutputTypeNamePair (CodeTypeReference type,
string name)
{
OutputType (type);
output.Write (' ');
output.Write (name);
}
This will work for several languages. E.g. C#, J#, Managed C++ and others -
even Java. However it will obviously not work for VB.Net. But IMHO it is a
good thing to avoid TRIPPLE code duplication within what gets shipped as ONE
framework - even if it is a little bit less clean because you have to
override that method for Visual Basic.
Also all of this 'mess' is not even visible to the outside world, its all
protected.
That's a good point. I agree that if a particular implementation is useful for more than one language then it's appropriate to put it in CodeGenerator.
I *think* that the methods I mentioned (OutputTypeAttributes, OutputMemberAccessModifier, OutputMemberScopeModifier) are totally C#-specific in that they wouldn't be correct for *any* other language. Even if they're technically correct for VB, they certainly don't give the conventional capitalization (Most VB Code I've Seen Capitalizes The First Letters Of Keywords Like This). In that case I'd argue that it's inappropriate for them to be in CodeGenerator. But I seem to be outvoted and I don't feel terribly strongly about it.
Why document if you can easily see which are inherited? CSharpCodeGenerator.cs is no template file for other Code Generation Engines but the implementation of CodeGenerator for C#
It's hard to tell the difference between methods that are inherited because the default implementation is good enough for many languages, and methods that are inherited because the default implementation is *specific* to C#.
*I* definatelly wouldn't like it. I've done quite some work on CodeDom (mostly VB stuff - e.g. VBCodeGenerator.cs). I also doubt that others will be happy if you just duplicate the code to make *the implementation* (not even a public accessible something) more 'stylish'.
Fair enough - I'm clearly outvoted on that one ;)
From the point of a user (myself) of the CodeDomain namespace:I know that lots of people aren't happy with it. At first you think that you found the coolest thing ever, but then you pretty fast realize that it can't be used for anything more that simple creation of stubs or super-small and trivial applications. In fact if you think a little bit about the whole problem you realize pretty fast that it is impossible to have something like CodeDomain for a language neutral framework because the maximum common ground you can find between all languages is the IL itself. And then you can as well use Reflection emit. The only way this would work was if every language would add its own laguage elements to CodeDom, however this would defeat the whole purpose of it. The thing that stroke me most after thinking that I just found the coolest thing ever with CodeDom was when I realized that CodeParser is not implemented at all in the .Net Framework ;) I first saw CodeDom and thought it should be possible to create a universal language converter in just a few minutes ;)
I'd heard so much bad stuff about CodeDom before I started working with it that I didn't have high hopes. It's actually less bad than I had expected. Clearly it's only possible to define something like CodeDom for a common subset of all languages, but for some tasks (like, as you said, stubs and super-trivial applications) it's a reasonable approach.
For ASP.NET I think it would be better if each language provided a compiler that could compile a "snippet" of code (an expression, a list of statements, or a 'class body chunk' with methods, properties etc in it) into a snippet of IL, and then have the ASP.NET implementation combine those snippets with precompiled IL code for all the boilerplate. But that's not the way MS chose to approach it, and CodeDom works well enough for the most part.
Having said that, there are several places where CodeDom is missing information that's critical to generate correct code in some languages. If your language distinguishes between interface and implementation inheritance, you just have to guess which of the specified base classes are interfaces - there's no way to get that information. If your language doesn't support properties or events or indexers explicitly, requiring you to call the underlying accessor methods, you have to just assume that the accessor methods are named according to the standard naming convention and that [IndexerNameAttribute] wasn't used, because you have no way to tell. I'm told that even Microsoft's J# CodeDom generates incorrect code for the equivalent of myString[0] - it produces myString.get_Item(0) instead of myString.get_Chars(0). Finally, if your language has special treatment for certain classes (such as object or string) you can't handle that properly in CodeDom because there's no way to specify what Type you expect a CodeExpression to evaluate to.
Absolutely. Glad to see you on board!
I have a preliminary patch but I haven't tested it yet. I'll send it as soon as I do.
Let me have a guess. Starts with 'J' and ends with 'ava'
Good guess!
:)
Stuart.
-- Stuart Ballard, Senior Web Developer NetReach, Inc. (215) 283-2300, ext. 126 http://www.netreach.com/
_______________________________________________ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
