Re: some things about Closure

On 7/17/26 10:37, Paul King wrote:
> Hi Jochen,
>=20
> I was about to send you an email but had cooking duties. Yes, for
> #2714, I asked Claude to take a best guess at your OpenClosure idea -
> not as a final design but as a rough guess to work backwards and see
> if #2709 was capable of supporting the design. So I do plan to look at
> it in more detail, but Claude thinks there is at least some path
> roughly in the direction you described and #2709 was good enough to
> support it. I am still going through #2709, #2714 would need even
> greater review with much greater scrutiny but maybe can wait until
> after beta-1 unless it looks wildly wrong in your eyes ? And there is
> probably more aspects from what you had in mind that we can feed into
> the design once we want to look at that piece for real.

Maybe some small points.

I noticed we are now adding a lot of groovy.target... properties, for=20
what I see as experimental features. I am wondering if we not should do=20
that differently, like groovy.incubating.... allowing us to remove the=20
flag later.... or do it like the VM and have an option that will unlock=20
experimental options. Maybe it is just my personal impression it is so=20
much. I am loosing track of what options we actually support. Which is=20
kind of the next point. in this matter.

For the gradle build, may I suggest to have a text file with the=20
properties we want to bridge? It is I think only three now, but it would=
=20
allow a central place to change this with only one file to edit. Well..=20
ok need also to edit the places it is assigned to. Would it be possible=20
to define those properties as Strings in a Java class we then use from=20
gradle as well as from the code itself? Never tried that. Then we could=20
work with constants, or even an enum. Just looking for a way to organize=
=20
the code a bit better here.

Now one elemental question in my eyes is support closures with default=20
parameters. That does actually not even have to be PackedClosure itself=20
if you are worried about the call path. We could have=20
PackedMultiArityClosure that would be almost the same as the fixed arity=
=20
variant, but uses the number of arguments to decide what method to call.=
=20
Since ware talking only about default values for parameters there is a=20
very specific, non-overlapping way how this is resolved and easy to=20
check at runtime. Does not have to be in the first version though.=20
Sometimes I think I see the try to support it and then I think I see=20
that it is not supported... I am a bit confused.

Also confusing is the dispatch table. Could you maybe sum up how the=20
call is actually done. I start thinking I am not seeing it clearly. I=20
mean from the caller of the Closure to the actual invoked method with,=20
how it is decided to invoke that and what invoke method (like=20
invokedynamic) are used to do so. And if tables are used, how they look=20
like. I am asking because I feel we could make the table different.. for=
=20
example using an array of MethodHandles, that are constants in the host=20
class, and decide the target without using findStatic in the bootstrap the=
n.



bye Jochen