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

[Stuart Ballard]

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.

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.

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?

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

-- 
Stuart Ballard, Senior Web Developer
NetReach, Inc.
(215) 283-2300, ext. 126
http://www.netreach.com/