On 21.01.21 02:10, Christopher Smith wrote:
Sorting the list should be inconsequential, but you seem to miss my
concern, which is about the loop nesting:
A) for each transform in list, visit each node
B) for each node, visit by each transform in list
In case B, transforms wouldn't entirely exec
Sorting the list should be inconsequential, but you seem to miss my
concern, which is about the loop nesting:
A) for each transform in list, visit each node
B) for each node, visit by each transform in list
In case B, transforms wouldn't entirely execute as distinct "layers" across
the compilatio
Hi Chris,
from what Eric said, it seems it is just some (linked) lists that are
being processed after the data has been collected, that sounds like
these would need to be replaced with a priority ordered collection or
sorted after they have been filled.
That does not sound too complicated in p
Hi Chris,
to make things clear: Would you offer to work on this feature, or is it
"just" a feature request on yopur part ?-)
In any case, your proposal sounds like a good idea. It is always amazing
to me, how many things are unecessarily hard or even impossible to do
because - by design - "t
You can have a look at org.codehaus.groovy.transform.ASTTransformationVisitor,
org.codehaus.groovy.transform.ASTTransformationCollectorCodeVisitor and
ultimately org.codehaus.groovy.control.CompilationUnit. The compiler phase
operation linked lists are what you are looking to order. Besides th
A longstanding shortcoming of the AST-transformation system is the
minimal guarantees provided when multiple ASTTs target the same area
of code. While comprehensive support for this seems like it would
require a redesign or at least major rework, I have a suggestion for a
small change that might ge
