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

[Andreas Nahr]

In Text


> I'm working on a CodeDom provider for a language that happens to look an
> awful lot like C#[1].

I've done the one for VB, so If you have any problems I might be able to
help.

> I thought it would be sufficient to start with Mono's
> CSharpCodeGenerator and go through it in detail, changing each construct
> to the equivalent in Ja^H^Hthe language I'm dealing with. This turns out
> to actually not be sufficient, though, because in several places
> CSharpCodeGenerator simply inherits an implementation from CodeGenerator
> which gives C#-specific behavior. Examples of this behavior are
> OutputTypeAttributes() and OutputMemberAccessModifier(), both of which
> are non-abstract in CodeGenerator and give pure C# output.
>
> This seems like an incredibly bad idea that defeats the purpose of
> having a language-independent API. I recognize that there are other good
> reasons why the CodeDom API sucks (I've already compiled a half dozen
> items in my wishlist of API features) but this seems to me like
> implementation suckage, not API suckage.

This does not seem to be a big problem to me. It may not be a perfectly
clean approach, but it certainly is rather efficient. And as MOST people
will probably just use CodeDom and not implement their own Provider - so
they probably don't care about the 'cleaness' of the implementation.

> It may be that this behavior is required to be fully compatible with a
> sucky MS implementation. If that's the case, there should be a prominent
> comment in the source of CodeGenerator explaining this. I'd also be
> tempted to duplicate the methods in CSharpCodeGenerator even though
> that's technically redundant, because it's closer to the correct
> separation of concerns between the two classes. If not, there should at

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.

> least be a large comment at the top of CSharpCodeGenerator documenting
> which methods it inherits from CodeGenerator that are C#-specific.

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#

> If I produce a patch to this effect, would it be accepted? Which
> approach should I take?
*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'.

>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 ;)

> If I'm correct about these behaviors being bugs, should I produce
> patches for them?

Absolutely. Glad to see you on board!

>
> [1] Can you imagine what that language could *possibly* be? ;)

Let me have a guess. Starts with 'J' and ends with 'ava'