groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Owen Rubel <oru...@gmail.com>
Subject Re: "External" closures, why?
Date Tue, 01 Dec 2015 16:58:45 GMT
Maybe I can help a little...

Like most things in Groovy, closures provide a convenience. They are
similar to methods but they are more 'compact' in that they can be embedded
in calls, as method variables (as their returned output is accepted as the
input for the method) , etc. They can be used places where methods can't be
used provide a level of simplicity and reducing verbosity of your code.

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

Anyone, Correct me if I'm wrong?

Owen Rubel
415-971-0976
orubel@gmail.com

On Tue, Dec 1, 2015 at 8:42 AM, alessio <alessino@gmail.com> wrote:

> 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 <soeren@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 (alessino@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
>

Mime
View raw message