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 execute as distinct "layers"
across the compilation unit but would rather be interleaved as the
compiler proceeds through the AST. In that case, the effect of ordering
is highly constrained.
In fact the compiler uses B on a per phase base. In each phase a
transform may cause a new source unit to be added to the compilation,
its class nodes then transitions though the phases, till they reach the
same phase as the current overall compilation is in.
But defining an order for a class node for transforms in the phase is
still possible and should cover almost all cases.
My problem is more identifying the transforms by name individually. Lets
say we have transform X in the compiler and transform U defined by the
user with U should run before X (U<X). Now imagine we add Y and it runs
before Y, we then have Y<X and U<X, does this mean Y<U or U<Y? Let's say
the user transforms should, if in doubt, run after the compiler
transforms, so we get Y<U<X.
Imagine the former U<X, but now we want to split X in X0 and X1 with
X0<X1. Since X does not exist anymore, where does U go? Or let us assume
we keep X1 as X, then we would get X0<U<X. If X0 is doing the bad part
for U we just broke the compilation process if U is used.
If you sort the transforms by number you get a similar situation. if X
had 10 and U 9, and now X1 has 10 and X0 has 9 (maybe 11 is in use by
another transform already), you get into the same problem for U and X0,
since they are both defined for 9.
Of course you can redefine things to let U run first and my example
suddenly works. But you can build a new one where it breaks again.
Basically I want to say I favor the numbers, since we do then not have
to expose implementation classes of the compiler and keep the name of
internal classes forever... and I think it will solve some cases... just
don't think it will solve everything and the next iteration of the
compiler may break it in a way that you would need different numbers
depending on the groovy version.
bye Jochen
