In #1759, the visitor adapter sets up some delegation between visit methods to allow matching eg all expressions.
This is cool and allows us to write more expressive visitors (it's argumented on #1759). But there are some problems with it:
- It's done by hand, and it's easy to forget some stuff, or getting something wrong with a copy-paste
- It's done in the adapter, which means AbstractJavaRule can't benefit from it unless we duplicate the logic.
- Java allowing a type to implement several interfaces, there can be conflicts in the delegation hierarchy.
- Some delegation paths seems more natural than others though, eg
visit(ASTInstanceOfExpression) delegating to visit(ASTExpression) instead of eg visit(TypeNode).
- I think delegation should completely ignore types that are there because of our implementation (like TypeNode, or AnnotatableNode), and only consider those that are in the grammar (eg ASTExpression, ASTTypeDeclaration, etc)
Ideally the visitor interface would have this delegation logic generated in default methods. This means we probably need to somehow augment JJTree to generate that (or write another generator).
Implementing this RFC gives us a strong basis to implement #1787.
In #1759, the visitor adapter sets up some delegation between visit methods to allow matching eg all expressions.
This is cool and allows us to write more expressive visitors (it's argumented on #1759). But there are some problems with it:
visit(ASTInstanceOfExpression)delegating tovisit(ASTExpression)instead of egvisit(TypeNode).Ideally the visitor interface would have this delegation logic generated in default methods. This means we probably need to somehow augment JJTree to generate that (or write another generator).
Implementing this RFC gives us a strong basis to implement #1787.