GEP-27 S1

Hi all,


there are some thoughts about GEP-27 I want to share.

First of all, compiling lambdas without going through a Closure is a=20
good thing. And I think that should always happen, in static and dynamic=
=20
code. I do not think that is the implementation in current Groovy 6.=20
What do we actually do if defaults are used for the lambda parameters? I=
=20
ahve the feeling we may handle this wrong right now.

Closures are more difficult because of the mutable state they carry and=20
because they are initially planed as inner class construct.

PackedClosure as in https://github.com/apache/groovy/pull/2692

Loss of GeneratedClosure.
This is not a marker interface for that we have a Closure generated by=20
the compiler as primary goal. The primary goal is to use this=20
information, that this is a controlled class without possible=20
shenanigans from the user to allow optimizations. Those are lost now. I=20
already commented on the huge amount of basically reflective code in=20
there. There is an abstraction we have for this and that would be=20
MethodHandles. I think It should get a MethodHandle as parameter, with=20
the handle beeing a constant in the hosting class and invoke it.
And again here I have to ask how defaults are handled? From the code I=20
see, not at all. The default variant is simply ignored. Of course a=20
single handle would then also not work. I am putting it here because I=20
think the default arguments problem must be discussed.

Then there is a lot of talk in the GEP and the PR about @DelegatesTo=20
indicating a delegation usage. Well, yes, CS can use that, but it really=
=20
is not enforcing. @DelegatesTo -> setDelegate most likely used, No=20
@DelegateTo -> setDelegate might still be used.


Which leads me to another point. MethodClosure.
In theory MethodClosure is in a similar situation. You cannot=20
effectively set the delegate. ClosureStrategy does not really work. But=20
we have a break in style here. MethodClosure is silently ignoring.=20
PackedClosure not. In theory MethodClosure and PackedClosure are the=20
same beasts, only that in case of PackedClosure we actually know the=20
target method(s) even in dynamic mode fully.

Just to make this clear. I think MethodClosure also needs a rework. But=20
then we should consider aligning PackedClosure and MethodClosure.

What do you think?

bye Jochen