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/
_______________________________________________ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list