Hi Rémi,

      Thanks for your explaination and suggestion. 
      The following email was sent by Jochen in another thread. The
implementation of lambda expression can be discussed here together :)

Cheers,
Daniel.Sun
----------------------------------------- Jochen's email
--------------------------------------
On 07.02.2017 17:39, Daniel Sun wrote: 
[...] 
> 
>   * We have a basic choice: 1) Use Java-lambda semantics or 2) 
>     Groovy-closure semantics. As a variation on 2, we can add some help 
>     for people pasting Java code into a Groovy program. 
> 
> 
> Agreed. 

hmm... let me add some thoughts to this... 

I see a lambda as a kind of lightweight proxy, that provides an 
implementation for a series of functional interfaces. In that matter 
they are like "closure as SomeFunctionalInterface", only that our 
solution is not lightweight. 

Since we know the internals we can ignore the proxy facade and directly 
use the method that realizes the proxy. All that is then required is to 
transform call arguments to the types the implementing method needs. 

It would be very possible to use the LambdaMetaFactory for for example 
"closure as SomeFunctionalInterface". 

At the same time we can provide our own LambdaMetaFactory (ignoring 
Java9 problems). The "problem" is the identity of the implementing 
method and what signature you use for it. In dynamic Groovy you can go 
with object for most parts and have no trouble. 

What we are really missing is the ability to decide at compile time 
between two overloaded methods each taking functional interfaces. Only 
this requires extended static analysis. If we delay that part to 
runtime, like we do today for SAM Closures, then we do not need this as 
long as the interfaces differ on a level recognizable after type erasure. 

if we have for example one method taking List  and another taking 
List as parameter type for the method of the functional interface, 
then we really really need a static analysis. 

In the end that boils for me down to: 
* dynamic Groovy can most probably not use LambdaMetaFactory and could 
probably use the already existing ifrastructure the invokedynamic port 
provides. 
* static Groovy can use LambdaMetaFactory but needs to be improved on 
the compiler level 

bye Jochen 




--
View this message in context: 
http://groovy.329449.n5.nabble.com/VOTE-About-the-implementation-of-lambda-expression-tp5738486p5738513.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Reply via email to