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