[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