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

[Stuart Ballard]

[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.

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/