Re: some things about Closure

Jochen Theodorou <[email protected]> Fri, 17 Jul 2026 10:24:51 +0200
Newsgroups gmane.comp.lang.groovy.devel
Message-ID <[email protected]>
Hi Paul,

I found PS #2714. I know it is a draft, so I will not bother with=20
details too much, but in PackeClosureBoundariesTest.groovy I found this=20
CALLS table where I have a few remarks.. oh yes, you can take them as=20
next stage or something, does not have to be in there right away and I=20
have the feeling that some of the points are to be discussed.

>         ['explicit this-property',       false, true,  'int field =3D 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=20
the static case. I think this is wrong. Yes, there is maybe MOP on=20
this.field, but it does not matter. The relevant part is "this" and=20
known. "this" in a literal Closure always refers to the enclosing class.

[...]
>         ['default parameter values',     false, false, 'def m() { def c =
=3D { int x =3D 1 -> x }; c(2) }'],

Conceptually, if multiple methods are now supported by PackedClosure=20
this should not decline.

[...]
>         ['returned',                     false, false, 'Closure m() { re=
turn { it } }'],>         ['stored to property',           false, false, '=
def m(Map=20
attrs) { attrs.handler =3D { 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 ---------------=
=2D---------------------------
>         ['cast to Serializable',         false, false, 'def m() { ({ it =
} as Serializable) !=3D null }'],
>         ['local into writeObject',       false, false, '''def m() {
>                 def c =3D { it }
>                 new ObjectOutputStream(new ByteArrayOutputStream()).writ=
eObject(c)
>             }'''],

not sure I understand these. We could support Serializable, right? But=20
what bothers me is that the usage of the cast or the OutputStream could=20
be in a library method. Then we would not decline the Closure, but fail=20
later in the library?

>         // ---- contexts the adapter cannot inhabit: declines everywhere=
 ---------------------------
>         ['intersection cast',            false, false, 'def m() { (Runna=
ble & java.io.Serializable) { -> } }'],

Isn't the keypoint here Serializable, not the intersection itself?=20
Casting to Runnable&Callable for example should be fine


bye Jochen