[Mono-list] Re: [Mono-devel-list] C#isms in CodeDom core and other bugs - willing to fix

[Stuart Ballard]

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
> 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/