Hi Cedric,
> De: "Cédric Champeau" <cedric.champ...@gmail.com>
> À: dev@groovy.apache.org
> Envoyé: Mercredi 19 Octobre 2016 09:09:51
> Objet: Re: Lambda expression for Groovy 3
> First of all, great work, Daniel ! I'm confident that making the "lambdas" be
> "closures" in Groovy is enough. I stated it in the past but I'm going to
> repeat
> myself here, I don't think having 2 syntax for "closures/lambdas" with
> slightly
> different semantics would help our users/language. That said, the static
> compiler can do better, doing escape analysis, and using "real" lambdas when
> the target bytecode is 8, as an optimization.
The main issue i see of having one semantics is that the meaning of 'this' in a
Groovy closure means the closure itself while 'this' in a Java lambda means the
enclosing object, so { -> this } in Groovy is a substitute to () -> this in
Java.
The choice seems to be, the semantics of 'this' in a lambda in Groovy can be
either the same as Java so you can copy/paste a Java code and it will work as
is in Groovy or the same semantics as in a Groovy closure so as you said you
will not have to explain why in Groovy { -> this } and () -> this do not return
the same value.
I have no opinion about that, i let you guys decide :)
That said, the lambda metafactory takes a desugared lambda as argument (a plain
old static method, apart in corner cases), so choosing the semantics of the
lambda in Groovy is orthogonal to the choice of using the lambda metafactory or
not.
Rémi
