groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remi Forax <fo...@univ-mlv.fr>
Subject Re: Lambda expression for Groovy 3
Date Wed, 19 Oct 2016 10:21:38 GMT
Hi Cedric, 

> De: "Cédric Champeau" <cedric.champeau@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 

Mime
View raw message