On 7/17/26 10:37, Paul King wrote:
Hi Jochen,
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
what I see as experimental features. I am wondering if we not should do
that differently, like groovy.incubating.... allowing us to remove the
flag later.... or do it like the VM and have an option that will unlock
experimental options. Maybe it is just my personal impression it is so
much. I am loosing track of what options we actually support. Which is
kind of the next point. in this matter.
For the gradle build, may I suggest to have a text file with the
properties we want to bridge? It is I think only three now, but it would
allow a central place to change this with only one file to edit. Well..
ok need also to edit the places it is assigned to. Would it be possible
to define those properties as Strings in a Java class we then use from
gradle as well as from the code itself? Never tried that. Then we could
work with constants, or even an enum. Just looking for a way to organize
the code a bit better here.
Now one elemental question in my eyes is support closures with default
parameters. That does actually not even have to be PackedClosure itself
if you are worried about the call path. We could have
PackedMultiArityClosure that would be almost the same as the fixed arity
variant, but uses the number of arguments to decide what method to call.
Since ware talking only about default values for parameters there is a
very specific, non-overlapping way how this is resolved and easy to
check at runtime. Does not have to be in the first version though.
Sometimes I think I see the try to support it and then I think I see
that it is not supported... I am a bit confused.
Also confusing is the dispatch table. Could you maybe sum up how the
call is actually done. I start thinking I am not seeing it clearly. I
mean from the caller of the Closure to the actual invoked method with,
how it is decided to invoke that and what invoke method (like
invokedynamic) are used to do so. And if tables are used, how they look
like. I am asking because I feel we could make the table different.. for
example using an array of MethodHandles, that are constants in the host
class, and decide the target without using findStatic in the bootstrap then.
bye Jochen
