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.
Cheers, Paul. On Fri, Jul 17, 2026 at 6:25 PM Jochen Theodorou <[email protected]> wrote: > > Hi Paul, > > I found PS #2714. I know it is a draft, so I will not bother with > details too much, but in PackeClosureBoundariesTest.groovy I found this > CALLS table where I have a few remarks.. oh yes, you can take them as > next stage or something, does not have to be in there right away and I > have the feeling that some of the points are to be discussed. > > > ['explicit this-property', false, true, 'int field = 1\ndef > > m(List<Integer> xs) { xs.collect { it + this.field } }'], > > If I read this right, it does not pack in the dynamic case, but does in > the static case. I think this is wrong. Yes, there is maybe MOP on > this.field, but it does not matter. The relevant part is "this" and > known. "this" in a literal Closure always refers to the enclosing class. > > [...] > > ['default parameter values', false, false, 'def m() { def c = { > > int x = 1 -> x }; c(2) }'], > > Conceptually, if multiple methods are now supported by PackedClosure > this should not decline. > > [...] > > ['returned', false, false, 'Closure m() { > > return { it } }'],> ['stored to property', false, false, > > 'def m(Map > attrs) { attrs.handler = { it } }'], > > ['in a collection literal', false, false, 'def m() { [{ it }] > > }'], > > Why is an escape of the Closure a reason to decline in these cases? > > > // ---- serialization-bound: declines everywhere > > ------------------------------------------- > > ['cast to Serializable', false, false, 'def m() { ({ it } > > as Serializable) != null }'], > > ['local into writeObject', false, false, '''def m() { > > def c = { it } > > new ObjectOutputStream(new > > ByteArrayOutputStream()).writeObject(c) > > }'''], > > not sure I understand these. We could support Serializable, right? But > what bothers me is that the usage of the cast or the OutputStream could > be in a library method. Then we would not decline the Closure, but fail > later in the library? > > > // ---- contexts the adapter cannot inhabit: declines everywhere > > --------------------------- > > ['intersection cast', false, false, 'def m() { (Runnable > > & java.io.Serializable) { -> } }'], > > Isn't the keypoint here Serializable, not the intersection itself? > Casting to Runnable&Callable for example should be fine > > > bye Jochen
