The following are breaking API changes, that I'd like to see done sometime
FormalParameter shouldn't be an access node
FormalParameter currently implements AccessNode, even though this is only because a parameter can be final...
The problem is also real for LocalVariableDeclaration
CatchStatement shouldn't use FormalParameter as a child
Because of that, FormalParameter's grammar implements the multicatch syntax, which doesn't really make sense and makes it difficult to enrich the API of the node in a sensible way.
- For example, methods that are only relevant to the formal parameter usage make no sense if the node is a catch statement (e.g. isVarargs), and conversely (isMultiCatch).
- For methods that can be used in both cases, the documentation is very complicated to write
- Most importantly, type resolution is inconsistent between the two cases
We should probably follow the JLS more closely for Catch formal parameters.
Resource shouldn't extend FormalParameter
It just doesn't make sense at all. ASTResource inherits isVarargs, isMultiCatch, all methods of AccessNode, etc...
The following are breaking API changes, that I'd like to see done sometime
FormalParameter shouldn't be an access node
FormalParameter currently implements AccessNode, even though this is only because a parameter can be final...
The problem is also real for LocalVariableDeclaration
CatchStatement shouldn't use FormalParameter as a child
Because of that, FormalParameter's grammar implements the multicatch syntax, which doesn't really make sense and makes it difficult to enrich the API of the node in a sensible way.
We should probably follow the JLS more closely for Catch formal parameters.
Resource shouldn't extend FormalParameter
It just doesn't make sense at all. ASTResource inherits isVarargs, isMultiCatch, all methods of AccessNode, etc...