opeongo Does congocc require the INJECT option to add code into the nodes?
Well, not exactly. Using INJECT is the preferred way of doing things, yes. But you actually do have the option of maintaining Node subclasses by hand.
I mean, the typical and preferred usage pattern would be something like:
AdditiveExpression :
MultiplicativeExpression ( ("+"|"-") MultiplicativeExpression )*
;
So, the code generation is going to generate a class, AdditiveExpression and that is in the NODE_PACKAGE, right? Furthermore, if you want to inject some code, like a custom method into that into that AdditiveExpression.java source file, you use INJECT, like:
INJECT AdditiveExpression :
implements Expression
{
public Expression getLhs() {
return (Expression) get(0);
}
}
Okay, the above is the preferred usage pattern. It has certain advantages, like the fact that the generated source file (in this case AdditiveExpression.java) is just regenerated each time (with the injected code) so, in terms of doing a clean rebuild of the project, things are quite clean. (Generating files and the subsequently post-editing them is not a good pattern!) Also, the above INJECT would typically be put right next to the AdditiveExpression production in the grammar file itself. So the code is just easier to read, since things that are relevant to one another are located in the same place.
Now, all that said, the above is the preferred usage pattern. But you can maintain the AdditiveExpression.java file yourself, and if you do that, it can be in any package you want.
The way you would do that is by fully specifying the package name in the grammar production. So you would write:
AdditiveExpression #com.mypackage.AdditiveExpression :
MultiplicativeExpression ( ("+"|"-") MultiplicativeExpression )*
;
When the node class is fully specified like that, it tells the system that it does not need to generate the class, you're taking care of it.
Actually, you can see that this is actually used internally somewhat. See, for example: https://github.com/congo-cc/congo-parser-generator/blob/main/src/grammars/CongoCC.ccc#L697
I decided to maintain BNFProduction.java separately by hand, but actually, it might be a fairly marginal decision. (See: https://github.com/congo-cc/congo-parser-generator/blob/main/src/java/org/congocc/core/BNFProduction.java ) The main reason to do that boils down to the fact that we don't have Java tooling inside the grammar file, so if the injected code in a Node subclass gets a bit hairy, we prefer to have auto-completion and the rest of it when editing the code, which we don't have when editing the code embedded in the grammar file. But the thing is that probably most of the times you inject a method into a Node, it's really pretty trivial, along the lines of getXXX/setXXX sorts of things, and there is not much need for any tooling. So the advantage of having the injected code very near to the grammar production is the bigger consideration. Of course, if there was decent tooling for editing CongoCC grammar files, then...
Well, anyway, that was a point that was on the tip of my tongue to point out, that if you have a bunch of hand-coded Node classes, you can take this approach. And then those hand-maintained source files can be in any package you want!
All that said, you would probably be better off gradually moving towards the more approved code pattern.
But anyway, the bottom line on hand-edited/maintained Node subclasses is that you can do that by fully specifying the package name in the grammar and then they can be in whatever package you want to put them in. But if you use the preferred coding pattern, then the files are generated in the NODE_PACKAGE package. So I hope that's clear now...