groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From MG <>
Subject Re: About the callable native lambda
Date Wed, 31 Jan 2018 22:01:07 GMT
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 :-) )

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...

"...only as a fallback if  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  doesn't exist" weaken the elegance of the whole concept too much ?


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
>   - SAM types: obj(params...) becomes obj.<sam-method>(params...) - perhaps only
as a fallback if 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 <> 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:
>> Cheers,
>> Daniel.Sun
>> --
>> Sent from:

View raw message