groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From MG <>
Subject Re: Ordering of AST transformations
Date Wed, 20 Jan 2021 22:08:25 GMT
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) :-)


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
> (; 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?

View raw message