On 19.10.2016 12:21, Remi Forax wrote:
[...]
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.
that is not the case anymore in any version since 1.0. We do make a
difference between the implicit and the explicit this though. The
implicit this has a cofigurable meaning, while the explicit this always
points to the enclosing class. So if you do {-> toString()}, you may get
the toString() of the Closure, the enclosing class, the owner (which
might be an enclosing closure) or the delegate. Which is why with static
compilation we have to do tricks here.
[...]
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.
if in a first step we map to Closure, then we won´t use the lambda
metafactory. If we do Closures similar to lambdas (which basically means
to get rid of Closure) Then the "resolution scope" for the implicit this
would have to become part of the method we map to
bye Jochen
