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

[Lluis Sanchez]

On dl, 2004-03-29 at 18:00, Stuart Ballard wrote:
> [Originally posted to mono-list only; I got no response there. Keeping 
> mono-list CC'd for thread-continuity, and because I'm not subscribed to 
> mono-devel]
> 
> I'm working on a CodeDom provider for a language that happens to look an
> awful lot like C#[1].
> 
> 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.

Those methods are virtual, you can (should) reimplement them in your
language generator class.

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

Some methods may emit C#-specific code by default, but since all those
methods are virtual, this is not a problem.

> 
> If I produce a patch to this effect, would it be accepted? Which
> approach should I take?
> 
> I've also encountered what I believe are some other bugs in
> CSharpCodeProvider:
> 
> - GenerateLabeledStatement is missing a ":" emitted after the label
> name, if I remember C# label syntax correctly.
> 
> - GenerateProperty attempts to determine whether to generate an indexer
> or not based on whether the name is Item. This is incorrect because Item
> is a perfectly valid name for a property, and an indexer can have a name
> other than Item. Instead, it should use the list of parameters to the
> property: If that list is non-empty, it's an indexer. In that case, if
> the name *isn't* Item, it should additionally generate an
> IndexerNameAttribute.
> 
> If I'm correct about these behaviors being bugs, should I produce
> patches for them?

Please do it!

> 
> By the way, on a completely unrelated note, is there a reason why Jeroen
> Frijters' excellent IKVM blog (http://www.ikvm.net/) isn't part of
> Monologue? The mono roadmap describes IKVM as a goal for Mono 1.0, so
> I'd definitely think that it's development weblog qualifies as "Mono
> related". Plus it's an excellent project that deserves more publicity
> than it gets, and Monologue is one small way to raise its profile, at
> least among Mono developers and users.
> 
> Thanks,
> Stuart.
> 
> [1] Can you imagine what that language could *possibly* be? ;)