[Mono-devel-list] Re: [Mono-list] C#isms in CodeDom core and other bugs - willing to fix
lluis at ximian.com
Tue Mar 30 05:32:39 EST 2004
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
> I'm working on a CodeDom provider for a language that happens to look an
> awful lot like C#.
> 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
> - 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
> 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.
>  Can you imagine what that language could *possibly* be? ;)
More information about the Mono-devel-list