Hi Jochen,
that sounds good :-)
(I have posted a conceptually different idea for implementing "inlined
'closure' blcoks" in the "Appended Block Closures" Jira ticket:
https://issues.apache.org/jira/browse/GROOVY-8301?focusedCommentId=16424692&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16424692
)
Cheers,
mg
On 04.04.2018 00:03, Jochen Theodorou wrote:
On 03.04.2018 19:17, mg wrote:
With regards to Groovy 3.0 Java lambda support: Is it practically
doable to turn a Groovy closure into a Groovy Java lambda if only
effectively final variables are used inside the closure ? And if yes,
might that be a future Groovy feature ?
My idea is to have a simple Closure object that has the required
information plus a handle for the method implementation(s) and that
this can be used internally with a special callsite to implement the
usage of the delegate and the resolution strategy. That means we my
not be able to use a lambda factory for this, but well, the
implementation would be similar to normal Java lambdas. Similar enough
to be able to use the exact same mechanism as lambdas in some cases. I
think with a bit thinking we would arrive at a more universal
mechanism usable for both... but maybe not with LambdaFactory like
Java does.
I am asking because otherwise there will exist two quite different
anonymous function syntax varieties in Groovy, with both most likely
being in active use, instead of one just existing for Java syntax
compatibility reasons. Which of course works, but feels a bit messy /
un-Groovy, and also can lead to code being executed slower than
possible, if someone uses Groovy closure syntax everywhere.
I think most cases of lambdas are operating on data they get. We could
define a closure like interface for these and convert a normal
Closures falling under that category to this new SAM Closure interface
instead.
Or would "closure inlining" support be the better approach here (also
with regard to implementation effort), since turning e.g. a forEach +
cls expression into a for-loop with the cls inlined as a block should
be even faster than using a Java lambda ?
I see what I described above actually as a required step for that kind
of inlining. You need that to be able to handle the pseudo Closures
you still require to handle strategies and special callsites. But I
see it possible
bye Jochen
