Community
Participate
Working Groups
20021022 It is currently not possible to subclass ASTNode as several abstract methods are declared package private. Are there strong reasons to prevent subclassing? We would like to add artificial elements to the AST tree.
Jim - any comment?
The AST API was intentionally designed around a closed set of AST node types that represent programs written in the Java language. Please say more about what you are trying to achieve by adding "artificial elements to the AST tree".
This is one idea: I would like to have a node that can stand for a arbitrary string of code. In the context of rewriting, I would extend our visitors (flattener, rewriter) to also handle the new node. MyNewNode.accept(visitor): if (visitor instanceof MyExtendedVisitor) { ((MyExtendedVisitor)visitor).accept(this) } Another idea is that I could introduce a artifical container node that groups a sequence of statements.
For an artificial container that groups a sequence of statements, you could use a Block node and mark it as special using get/setProperty. Similarly, an arbitrary string of code could be carried in a property on any type of ASTNode. More generally, you can use a property to carry other ASTNodes.
Is this good enough? Ok to close?
Why would you need to attach these directly as nodes ? AST nodes are representing all known legal Java constructs. Your specific ones rather seem related to outputting source. You could remember your specific objects through a map keyed by ASTs, and do whatever you want with them.
It's not that I can't solve the given examples (its all working in ASTRewrite with properties and maps, as you suggested), but I feel that being able to define your own AST nodes would make the infrastucture even more powerful. To make changes in place looks more convenient to me, especially in combination with an extended visitor. I wrote the bug report to find out if the closed world assumtion is essential in the AST code, or if it was just a design decision that that could be loosened. If it could be, I would vote to give the freedom to the AST-client. ok to close.
I believe the DOM should not be extensible, so that other clients can manipulate it as well in a predictable way. Think of AST evaluation for instance, would they recognize your specific nodes ? Closing.
