Comments on: Why I Love Closures

By: joeygibson

joeygibson — Sat, 11 Oct 2008 14:39:21 +0000

Jacob, you’re still going to know exactly where the problem occurred. Any exception that is thrown will still have line numbers and anything else you’d expect to find. There’s no obfuscation of problem location.

By: Jacob Nikom

Jacob Nikom — Fri, 10 Oct 2008 23:15:50 +0000

Hi,

I wonder what closure delivers when an error happened. In that Java example if something wrong happened when I am closing the connection, I know where it happened. Java will be able to report exact line number, because at minimum one statement corresponds to the particular action. With closure we have more actions than statements. Closure hides this clear correspondence from me by adding addition layer.

IMHO, it is better to have more lines of transparent code than fewer lines of obscure code.

By: joeygibson

joeygibson — Thu, 09 Oct 2008 17:26:50 +0000

Anthony, I see your point. I probably didn’t make the case as clearly as I wanted. That comment was in response to someone who suggested using some features from a 3rd-party library. I was trying to say that the fact that the languages support closures allows you to do this sort of thing, without needing another library.

By: Anthony Jayasekera

Anthony Jayasekera — Thu, 09 Oct 2008 17:07:27 +0000

“My point was that Ruby and Groovy allow you to do cool things, because of what’s in the language and its library, out of the box.”

That is not really an argument for closures though is it.

By: Randal L. Schwartz

Randal L. Schwartz — Thu, 09 Oct 2008 15:59:36 +0000

And of course, Perl has had closures since the beginning of Perl 5, which was back in the pre-Internet days (1995-ish). There’s even an entire book dedicated to Perl’s closures… MJD’s “Higher Order Programming”. Perl: those who do not study it are doomed to reinvent it, badly.

By: Paul King

Paul King — Thu, 09 Oct 2008 11:47:11 +0000

Oops, just checked the code again. My bad – I don’t know what I was thinking the other day – I must have been suffering from more lack of sleep that normal that day. You and Gordópaz are correct. Resources are closed only if you are using DataSources even with connection or statement caching in place. Sorry about the confusion.

By: Gordópaz

Gordópaz — Wed, 08 Oct 2008 18:58:33 +0000

Re: “… I used the eachRow method …”

In Groovy, eachRow closes the resources ONLY if the connection provider is a DataSource. When the groovy.sql.Sql instance is created using a Connection instead of a DataSource, closing the connection is up to the calling code.

By: Paul King

Paul King — Mon, 06 Oct 2008 20:26:38 +0000

By all means, consider a wrapper object if you think your circumstances require it, but JDBC drivers are pretty optimised these days. On top of which if you are using a pool, you will likely have some very good connection management going on. Then at least in 1.6-beta-1 and above you can always do sql.cacheStatements = true to turn on prepared statement caching within the Sql object (which implies connection caching) or alternatively use the cacheConnection() method which takes a closure and uses the same connection for all sql method calls within the closure. Some of this might not be documented well yet but hopefully will be before 1.6 final.

By: joeygibson

joeygibson — Mon, 06 Oct 2008 16:50:37 +0000

Paul, that actually seems like the wrong thing to do. What if I want to do several selects against the same connection? I’ve actually written a wrapper for the Sql object that does what I want. I haven’t fully tested it yet, but I was able to write the code in Groovy that looked almost just like the code in Ruby.

By: Paul King

Paul King — Mon, 06 Oct 2008 13:34:56 +0000

Re: “… I used the eachRow method …”

Yes, just checked the source code and (at least in trunk) every variation of eachRow that I could find closes the resources. This may not be the case for very old versions of Groovy, not sure, but fisheye and svn have all of the history.

Cheers, Paul.