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