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 - "the order of execution" of operations "cannot be
guaranteed". While potential execution in parallel is often given as a
reason for this, the design often predates these notions, so in reality
there often is no good explanation except the all time classic: It was
easiest to implement to do things in some sort of internal or natural
order ;-)
I had a quick look at Spring @Ordered, and they use int values for the
ordering. From the top of my head it feels it might be a good idea if we
used String or BigDecimal instead, since that should guarantee that one
can always fit another value between existing ones (by adding another
letter / digit) :-)
Cheers,
mg
On 20/01/2021 08:01, Christopher Smith wrote:
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 get a large segment of use cases working.
I propose adding "order" directives to transforms akin to Spring's
@Ordered and @AutoConfigureBefore/After. The sole effect of these
directives would be to instruct the compiler to run identified
transformations in sorted sequence.
As a specific hands-on use case, there's been a feature request open
against Spock for 5 years to support stateful traits
(https://github.com/spockframework/spock/issues/83); the impediment is
that both Spock and traits are implemented as SEMANTIC_ANALYSIS ASTTs,
so that Spock doesn't see the trait fields with their @Shared
annotations when it runs.
Is something like this feasible, or does it conflict with existing
sequencing or traversal requirements inside the compiler processing?
