groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesper Steen Møller <jes...@selskabet.org>
Subject Re: About the callable native lambda
Date Thu, 01 Feb 2018 11:50:28 GMT

> On 31 Jan 2018, at 23.01, MG <mgbiz@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 <realbluesun@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
>> 
> 


Mime
View raw message