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<A> and another taking
List<B> 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
