[Mono-list] Re: [Mono-devel-list] C#isms in CodeDom core and other bugs - willing to fix
sballard at netreach.com
Wed Mar 31 09:10:15 EST 2004
Andreas Nahr wrote:
> 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
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
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 - 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'
Stuart Ballard, Senior Web Developer
(215) 283-2300, ext. 126
More information about the Mono-devel-list