groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Winnebeck, Jason" <Jason.Winneb...@windstream.com>
Subject RE: "External" closures, why?
Date Tue, 01 Dec 2015 20:24:22 GMT
What was recently added is that you don't need to explicitly cast a closure to a SAM (single
abstract method), which was adding a feature to match Java 8 lambdas (that also don't need
a cast). So if you have a method taking an SAM, you no longer need to explicitly cast:

interface X { void xf() }
void func(X x) { x.xf() }

func { println "Hello, World!" }

It used to be before Groovy 2.2 that you had to call func this way:

func({ println "Hello, World!" } as X)

Closures are the closest equivalent to Java lambdas, but they do more than lambdas because
they support delegation (this is similar to setting "this" in JavaScript closures, except
in Groovy you detain both the delegate and the original "this" -- as the "owner" field). Closures
can also be queried for the number of arguments they take, allowing overloading of closures
that I don't believe is possible with Java 8 lambdas. And of course with Groovy closures work
back to Java 5, so if you can't use Java 8 yet, you can use Groovy.

As for "function pointers" like in C, Groovy has method closures:

X x = { println "Hello, World!" }
def method = x.&xf
method()

Unlike function pointer in C, the method closure memorizes both the "this" and the method
used. This allows for a very flexible "callback" or "observer" pattern in Groovy where you
can pass in an interface, Closure, or a method (via a MethodClosure):

button.onClick( new ClickListener() { ... } ) //anonymous class
button.onClick { println "Clicked!" }
button.onClick this.&onOkClicked

Jason

-----Original Message-----
From: alessio [mailto:alessino@gmail.com] 
Sent: Tuesday, December 01, 2015 2:57 PM
To: users@groovy.incubator.apache.org
Subject: Re: "External" closures, why?

On Tue, Dec 1, 2015 at 5:44 PM, Jochen Theodorou <blackdrag@gmx.org> wrote:
> The syntax is not new, Groovy had this kind of "attached block" since pre Groovy 1.0
times.

Alright, I did just run the code with against 2.0 (which was supposed not to support it) and
it ran just fine.

But then, what does the documentation refer to when it says one can omit an explicit coercion
as of 2.2?

>
> This kind of block usage w

Something is missing here.

On Tue, Dec 1, 2015 at 5:58 PM, Owen Rubel <orubel@gmail.com> wrote:
> Maybe I can help a little...

Thanks, appreciated!

>
> This is especially useful if it is something like a method call that 
> only gets called once. Why create a method for it? Just use a closure. 
> :)
>
> Closures provide tons of convenience over methods. They are not meant 
> to replace them at all but act as a convenience method

In my understanding that is just a function pointer (good old C :) ) or - if one likes it
better - an anonymous function or - if someone likes the Java term better :) - a lambda.

So far so good, the concept itself is not that much of a problem, the thing that I was simply
wondering (and which confused the heck out of me :) ) is the choice to support mentioned form
of passing the closure, which IMVHO could be utterly confusing, as the passed function is
VISUALLY not part of the function call but "dangling"
somewhere near it.

Thanks again!

----------------------------------------------------------------------
This email message and any attachments are for the sole use of the intended recipient(s).
Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the
intended recipient, please contact the sender by reply email and destroy all copies of the
original message and any attachments.
Mime
View raw message