Why Groovy should have corporate backing: Fund development! Dealing with comment spam with MT-SCode
Jan 14

Groovy Closures

Groovy, Tech Add comments

Mike has put together another well researched article on Groovy Closures.

He discusses what they are, how they work now, and some ideas on how he would fix them.

In Mikes world you would end up going from:

[1, 2, 3, 4].each { | param | println param }

to (params, clos keyword, no more |, no optional ;):

[1, 2, 3, 4].each (clos(param) { println param });

NOTE: Although Mike shows the form: { foo | … } Groovy supports { | foo | … } and has even talked about enforcing that.

I understand his points, and from a Java perspective it makes even more sense. However I think Charles Miller had a really good point… showing the power of perspective :)

Other things you complain about are very Ruby-like, but it helps to phrase them differently. For example, Ruby hackers wouldn’t say that a return statement was optional, they’d say that all methods return the value of the last statement in the method, but this behaviour can be overridden by an explicit return. (It’s a subtle difference of point-of-view).

Similarly, in Ruby, you wouldn’t say that semi-colons are optional. You’d say that the newline was the default statement separator, but you can force an end-of-statement with a semi-colon.

It is funny how actual work changes things. The more code I write in languages which don’t require a ‘;’ every 30 keystrokes, the more it bugs me when I have to go back to typing them, and more importantly seeing them on every line or so. What a load of clutter! :)

Comments are closed.