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:
Where:
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.
Jason
-----Original Message-----
From: alessio [mailto:aless...@gmail.com]
Sent: Tuesday, December 01, 2015 11:42 AM
To: users@groovy.incubator.apache.org
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 <soe...@glasius.dk> 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 (aless...@gmail.com ) 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
> (http://docs.groovy-lang.org/latest/html/api/groovy/sql/Sql.html)
> 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
>
> http://www.groovy-lang.org/semantics.html#_calling_a_method_accepting_
> a_sam_type_with_a_closure
> https://issues.apache.org/jira/browse/GROOVY-6188 (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.
