The PR is ready for another review. I hope to be ready to kick off a beta-1 release in a few days but let me know if you think it needs more work.
On Fri, Jul 17, 2026 at 10:35 PM Jochen Theodorou <[email protected]> wrote: > > 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 >
