[antlr-interest] CSharp3 code generation suggestions

[Sam Harwell]

1. I’ll make this change for all references to the Antlr namespace (using
statements and base classes). To change the base class of a grammar, you can
use “@lexer::superClass{global::Antlr.Runtime.Lexer}” (non-combined grammars
may omit the lexer::, and any type name may be specified as the superClass).

 

2. You can use @lexer::modifier{internal} to control access to the classes.
Use @lexer::ctorModifier{private} if you’ve declared your own constructor(s)
and need to prevent external code from using the generated ones. Section 5.1
of the C# 3 documentation shows this new feature (added for the 3.4
release).

 

3. I use Code Contracts with rewriting extensively in one of my other (side)
projects. For now it’s a love/hate relationship, but the real reason I
haven’t annotated the existing code is there are some big questions about
the compatibility of the CC library with the BSD license used for the
runtime.

 

Sam

 

From: Ranco Marcus [mailto:ranco.marcus at epirion.nl] 
Sent: Friday, August 12, 2011 3:59 AM
To: antlr-interest at antlr.org
Cc: Sam Harwell ‎[sharwell at pixelminegames.com]‎
Subject: CSharp3 code generation suggestions

 

Hi Sam,

 

I have a few rather small suggestions for the code generated by the CSharp3
target.

 

1. We used to have a namespace XXXX.Antlr in the same project as where our
grammars are located. The compiler fails when it tries to resolve the
generated grammar's base classes (Antlr.Runtime.___) and the included
namespaces (using Antlr.___ ). Maybe you could make this explicit by
prefixing those reference with global::.

 

2. The generated grammars are public by default. If the visibility modifier
would be omitted from the partial class declaration, the grammar would be
internal by default (something I usually prefer). In case somebody wants the
grammar to be public, he/she only needs to add another partial class
definition with a public modifier.

 

3. We are currently in the process of annotating our code with code
contracts (see 

http://msdn.microsoft.com/en-us/devlabs/dd491992.aspx, separate assembly in
.NET 3.5, included in the BCL in 4.0). The static checker (freely available
for VS Premium or above) is able to check after compilation where contracts
might be violated. Very cool stuff and maybe something to consider for the
Antlr runtime.

 

These are only suggestions, as none of the above are show-stoppers.

 

Best regards, 

 

Ranco