Re: About the native-lambda branch

Am 12.01.2018 um 04:05 schrieb Daniel Sun: Hi Nathan, What's will the differences be between closures and lambdas? The native lambda will have better performance than closure. In addition, native lambda, which conforms to Java specification, is less versatile than closure, which is really

Re: About the native-lambda branch

Hi Jochen and Daniel > On 12 Jan 2018, at 12.48, Jochen Theodorou wrote: > > > > Am 12.01.2018 um 04:05 schrieb Daniel Sun: >> Hi Nathan, >>> What's will the differences be between closures and lambdas? >> The native lambda will have better performance than closure. In

Re: About the native-lambda branch

Hi Jochen, > I did also not understand the innclass attribute visit... I've cleaned up the useless code: https://github.com/apache/groovy/commit/6aeaa1c5a7863af5d2c126a5bdf9da9aff2a8db6 Cheers, Daniel.Sun -- Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Re: About the native-lambda branch

On Fri, 2018-01-12 at 05:54 -0700, Daniel.Sun wrote: > […] > As you see, the latest implementation is to generate method for lambda > at the class generation stage, in addition new inner classes will be > generated for each lambda. > > […] I haven't read the code, I am reacting to the above

Re: About the native-lambda branch

Am 12.01.2018 um 14:13 schrieb Daniel.Sun: Hi Jesper, The bytecode generation for lambda of the current implementation should be somehow same with javac does, because I reference the ASM code, which is decomplied from bytecode generated by javac. If you have some spare time to

Re: About the native-lambda branch

Am 12.01.2018 um 15:00 schrieb Daniel Sun: Hi Jochen, but I think you should then not use the closure inner class mechanism. I remain the implementation for non-native lambda[1] to make lambda work in legacy code, where closures are widely used. For example, `[1, 2, 3].collect(e -> e + 1)`

Re: About the native-lambda branch

Am 12.01.2018 um 18:54 schrieb Russel Winder: On Fri, 2018-01-12 at 05:54 -0700, Daniel.Sun wrote: […] As you see, the latest implementation is to generate method for lambda at the class generation stage, in addition new inner classes will be generated for each lambda. […] I

Re: About the native-lambda branch

Sure thing. Here's a Java example: void sample(Function fn) { System.out.println("fn"); } void sample(Supplier sp) { System.out.println("sp"); } These methods can exist side by side, and are called correctly even in

Re: Making @Immutable a meta-annotation

Hi Paul, I think the core of the problem is, that @Immutable as a meta-annotation woud be better off being called something along the line of @ImmutableCanonical (see: If you do no need the immutability, use @Canonical), since it does not solely supply immutability support - then it would be

Re: About the native-lambda branch

One of the largest reasons I found myself preferring Groovy over Java is the quasi-final scoping restrictions of Lambdas. Please do not let this behavior exist in Groovy. It makes functional programming very hard. On the other hand, lambdas are superior for functional programming because they can