[antlr-interest] Q: opinions on ikvm + antlr3 ?
C. Mundi
cmundi at gmail.com
Fri Feb 6 07:50:25 PST 2009
On Fri, Feb 6, 2009 at 2:03 AM, Johannes Luber <JALuber at gmx.de> wrote:
>
> Con: I haven't checked it, but I believe that IKVM won't create the
> .NETisms like properties instead getters and setters. If true, your parser
> backend will be schizophrenic regarding the approaches.
Ouch! I need to check on that. Thank you for alerting me to this!
> Con: .NET-only additions like #pragmas to silence warnings won't be
> inlcuded.
>
I could probably manage that, but it would be more work. Good point.
FYI: Another approach to use the Java code as baseline is using the tool
> "sharpen" from the db4o team. It takes Java source code and transform it
> into C# code, which uses properties, etc. Cons are that you have to add
> annotations to the Java code and you may have to move untranslatable code
> into extra classes, for which you have to provide manual replacements.
Sounds dangerous, but worth researching. Thanks for the idea.
> Furthermore, you can't simply provide .NET-specific optimizations without
> doing a potentially harmful change to Java target or having to maintain code
> manually, if you can't teach sharpen about this special case. Another
> problem would be if other targets would want to go the same route. Then the
> Java code is going to be cluttered even more - which wouldn't be practicable
> or requiring some kind of annotations-standard for sharpen-like tools.
I see your point. This would definitely be a mess for multiple targets.
But for a time-limited project which is only ever going to target C#, this
would not be an issue. So I will give it some thought. Having the C#
properties is very tempting.
Thank you for your insightful help.
C. Mundi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.antlr.org/pipermail/antlr-interest/attachments/20090206/ed90dd73/attachment.html
More information about the antlr-interest
mailing list