metacircle
metacircle

Reputation: 2588

Antlr generated classes access modifier to internal

I am building a library which contains certain parsers. These parsers are internally built with ANTLR4. Since the generated classes are all public, users of my library are able to see all the classes they do not need to see. Also the Sandcastle documentation contains all these classes. Is there any way I can tell Antlr to make the generated classes internal instead of public?

Upvotes: 7

Views: 1228

Answers (5)

Sergey Kalinichenko
Sergey Kalinichenko

Reputation: 726969

C# target of ANTLR3 supports '@modifier'. For example, to make generated classes internal, you write

@modifier{internal}

If your parser source is split across multiple source files (e.g. lexer, parser, and tree) then each file is allowed to have its own modifier.

Upvotes: 0

Yarik
Yarik

Reputation: 1578

Actually, it's relatively easy to do. Internally, ANTLR uses StringTemplate files to generate code for each of the supported languages. For C#, you can find the template here in the ANTLR's JAR file:

org\antlr\v4\tool\templates\codegen\CSharp\CSharp.stg

Just make a copy of this file, and modify it as needed. For example, I usually remove CLSCompliant(false) attributes to get rid of the compiler's warnings, and make all the classes and interfaces internal.

Then, you need to tell the ANTLR to use the modified template during code generation. In order to do this, you need to put it in the CLASSPATH before ANTLR's JAR, and make sure that you keep the original folder structure, so that you point to a folder where the org directory is located, not to the CSharp.stg itself.

Here is an example of the folder structure that you can use:

enter image description here

In this case, Generate.bat should look something as follows (assuming that java.exe is in your PATH):

pushd %~dp0
set CLASSPATH=.;antlr-4.7-complete.jar
java org.antlr.v4.Tool -Dlanguage=CSharp Grammar.g4

Happy coding!

Upvotes: 2

GRosenberg
GRosenberg

Reputation: 6001

One quite effective approach is to implement a facade over the Antlr generated code while at the same time obfuscating the generated code. This gives you clear, independent control over what your users can see and use. The ProGuard obfuscator well handles this type of use.

Upvotes: 0

Onur
Onur

Reputation: 5211

You could modify the string templates.

You might start here.

I have never done this myself to be honest and you might have to repeat the step once a new release is published (although the merge will help you, you will still have to check if there are new "public"s).

Upvotes: 0

Terence Parr
Terence Parr

Reputation: 5962

We have not implemented public/private on the generated classes yet I don't think.

Upvotes: 1

Related Questions