> On 31 Jan 2018, at 23.01, MG <mg...@arscreat.com> wrote: > > Hi Jesper, > > seen from a Groovy user perspective your proposal seems to make sense to me. > (I would at the same time hope you do not dent Daniel Sun's enthusiasm too > much, because as far as I can tell he is currently doing alot of the heavy > lifting in this project :-) ) > Yes, he is - and the lambda work has come a long way - I'm testing some scenarios, so i hope to lift a little, too!
> How do you think what you propose fares with regards to "the principle of > least surprise" ? Are there any cases where this could lead to hard to track > bugs / unexpected behavior ? From the top of my hat, that would be my biggest > concern... I see static and dynamic as different concerns: For dynamic invocation, there could be some surprises, like example posted by 'avafanasiev' on GitHub: class R implements Runnable { void run(){}} def m(Runnable r1, R r2, r3) { r1() r2() r3() } m(new R(), new R(), new R()) Currently, in the 'native-lambda' branch, r1() succeeds, whereas the latter two fail to run/compile (depending on dynamic/static compilation), as 'avafanasiev' commented on. I do find that confusing: Dynamically, my opinion is that the three should work the same. For static compilation, r1() and r2() should work IMHO, and r3() should be rejected. This shouldn't surprise anyone, I think. Also, surprise-wise, class Q implements Runnable, Predicate<String> { void run(){}; boolean test(String s) { s } } def n(Runnable q1, Predicate<String> q2, Q q2, q3) { r1() r2() r3() } m(new R(), new R(), new R()) > "...only as a fallback if obj.call doesn't exist" seems like the safer > choice in this regard. Default behavior could also be made overridable by a > class annotation (then it would become the programmer's responsibility, to > make sure least surprise is not violated). > Without that the question to me is: Would choosing "fallback if obj.call > doesn't exist" weaken the elegance of the whole concept too much ? > > mg > > > On 31.01.2018 10:00, Jesper Steen Møller wrote: >> Hi list >> >> FYI: This turned into a discussion of the feature itself, on the GitHub >> commit thread. Basically, I'm proposing changing what "obj(params...)" means: >> - Non-SAM types: obj(params...) becomes obj.call(params...) >> - SAM types: obj(params...) becomes obj.<sam-method>(params...) - perhaps >> only as a fallback if obj.call doesn't exist. >> >> This should be completely independent of how the lambda object itself was >> created. >> >> I realize this is a potentially breaking change, but isn't it also a nice >> one? >> Thoughts? >> >> -Jesper >> >>> On 31 Jan 2018, at 03.16, Daniel Sun <realblue...@hotmail.com> wrote: >>> >>> Hi Jesper, >>> >>> I think your suggestion is very nice and I've completed callable native >>> lambda according to option 2 :-) >>> >>> Here is the related commit: >>> https://github.com/apache/groovy/commit/c24c0b7e6a67dcdf277207d4261cfa6f2b55031f >>> >>> Cheers, >>> Daniel.Sun >>> >>> >>> >>> -- >>> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html >> >