There are some problems with the granularity of the PCS representation of the Spoon ASTs. In particular, involved nodes such as methods that have many types of children can have different children interfere with each other. For example, take this method.
int div(int numerator, int denominator) throws ArithmeticException {
return numerator / denominator;
}Currently, for each node, Spork just gets its direct children as the child list. This is fine for simple nodes, but with this method node there's a problem.
The direct children of the method node (not counting content such as modifiers and method name) are the return type, the parameters, the thrown types and the body. Now, if we simply represent this method node's child list like this:
int, int numerator, int denominator, ArithmeticException, { return numerator / denominator }, it makes unrelated syntactical elements adjacent to each other, such as the end of the parameter list and the beginning of the thrown types list. If we create two derivatives of the above method, adding a parameter in one and adding a thrown type in the other, there's an insert/insert conflict across syntactical boundaries.
int div(int numerator, int denominator) throws SomeOtherException, ArithmeticException {
return numerator / denominator;
}int div(int numerator, int denominator, int uselessParameter) throws ArithmeticException {
return numerator / denominator;
}Here, one child list will read ... int denominator, SomeOtherException, ArithmeticException, and the other int denominator, int uselessParameter, ArithmeticException, creating an insert/insert conflict. This is not great.
A solution to this problem is to add intermediate virtual nodes where necessary. For example, a method node should not have its parameters as direct children, but should instead have a parameters node which in turn has the parameter list as children. Spoon's roles can be used to determine where to put which thing.
Only nodes where this is a problem should have intermediate virtual nodes added, as otherwise the PCS representation will absolutely explode in size.
There are some problems with the granularity of the PCS representation of the Spoon ASTs. In particular, involved nodes such as methods that have many types of children can have different children interfere with each other. For example, take this method.
Currently, for each node, Spork just gets its direct children as the child list. This is fine for simple nodes, but with this method node there's a problem.
The direct children of the method node (not counting content such as modifiers and method name) are the return type, the parameters, the thrown types and the body. Now, if we simply represent this method node's child list like this:
int, int numerator, int denominator, ArithmeticException, { return numerator / denominator }, it makes unrelated syntactical elements adjacent to each other, such as the end of the parameter list and the beginning of the thrown types list. If we create two derivatives of the above method, adding a parameter in one and adding a thrown type in the other, there's an insert/insert conflict across syntactical boundaries.Here, one child list will read
... int denominator, SomeOtherException, ArithmeticException, and the otherint denominator, int uselessParameter, ArithmeticException, creating an insert/insert conflict. This is not great.A solution to this problem is to add intermediate virtual nodes where necessary. For example, a method node should not have its parameters as direct children, but should instead have a
parametersnode which in turn has the parameter list as children. Spoon's roles can be used to determine where to put which thing.Only nodes where this is a problem should have intermediate virtual nodes added, as otherwise the PCS representation will absolutely explode in size.