groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Winnebeck, Jason" <>
Subject RE: "External" closures, why?
Date Tue, 01 Dec 2015 16:59:48 GMT
Groovy's syntax was confusing for me first as well. It looked extremely magical to me. But,
now that I know it, it really enables very strong and clear DSLs and I'm happy everything
is there.

In particular, Spock was wild to me. I was actually a few hours into reading about Spock before
I realized it was actually Groovy code. It stretches the DSL concept so far that I honestly
thought it was a separate language. I actually was almost about to drop Spock thinking I didn't
want to have to learn Groovy and another "proprietary" language. In particular, I did not
realize spaces were allowed in method names, and I didn't realize AST existed, which makes
the following work:

a | b | c
1 | 2 | 3

And def "this is really a method"() { } is really a valid method declaration.

Spock probably took AST too far. Things like @Canonical make sense, but Spock's AST changes
the meaning of the language, reusing only the syntax. That said, now that I know how Spock
works and how to use it, I love it. But I love it like VIM. Both have a very high barrier
to entry and secret arcane knowledge is required to perform even the most basic of tasks.


-----Original Message-----
From: alessio [] 
Sent: Tuesday, December 01, 2015 11:42 AM
Subject: Re: "External" closures, why?

Hi Søren,

thank you for the swift response. I understood that the "formal" way is still possible *),
I am just literally puzzled as to why the syntax would provide for this kind of alternative
in the first place.
Maybe I am old-fashioned **) but to me this seems extremely confusing as it looks like a fusion
of a traditional method declaration combined with a possibly following block statement and
a pinch of a "dangling"
anonymous function/closure/....

Apologies if I may seem nitpicking, the syntax is (partially) new to me, but the syntax really
left me bewildered (particularly because I have the impression such a freely dangling closure
is only possible in THAT context and nowhere else).

Thanks again :)

*) From what I deduced, it only works if the method expects the closure as ultimate argument.
In that case it can be appended outside, otherwise not. Would that be correct?
**) Yes, I havent fully dived into Groovy's support for the omission of parenthesis and commas
either yet - maybe I shouldnt :)

On Tue, Dec 1, 2015 at 5:23 PM, Søren Berg Glasius <> wrote:
> Hi Alessio,
> It's not a problem to use the closure like this:
> sql.eachRow('select * from PROJECT where name=:foo', [foo:'Gradle'], {
>   // process row
> })
> it is simply a matter of how you place your parentesees
> When you use closures with collections you would offen omit the 
> parentheses all together:
> collection.each {
>    // do something with it
> }
> but writing
> collection.each ({
>    // do something with it
> })
> yields the same result, but is a tiny bit more verbose
> Best regards / Med venlig hilsen,
> Søren Berg Glasius
> Hedevej 1, Gl. Rye, 8680 Ry, Denmark
> Mobile: +45 40 44 91 88, Skype: sbglasius
> --- Press ESC once to quit - twice to save the changes.
> On December 1, 2015 at 17:19:07, alessio ( ) wrote:
> Hi,
> I have just started to dig into Groovy and have been mostly impressed 
> by what it offers, however when I had a look at handling database 
> calls 
> (
> I stumbled upon a rather weird syntax
> sql.eachRow('select * from PROJECT where name=:foo', [foo:'Gradle']) { 
> // process row }
> Usually I'd say this is a "regular" block scope but in this context it 
> was obviously a closure/function pointer/callback. It took me a while 
> to dig into this to find out that it can also be passed as second 
> argument to the method and was added in 2.2
> a_sam_type_with_a_closure
> (the JSR link does 
> not work anymore)
> My question now is, why? Apparently pre-2.2 one had to cast the 
> closure to the appropriate type. But why making it possible to 
> actually define the closure outside of the respective call?
> At least for me this is HIGHLY confusing.
> Thanks

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.
View raw message