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
