![[info]](http://l-stat.livejournal.com/img/userinfo.gif){kind=small}
The code bellow shows how Java annonynous inner classes are just static typed closures, with all verbosity but also all behaviour needed :-)
2:
3:public class VerboseClosures {
4: public static void main(String[] args) {
5: MyList langs = new MyList();
6: langs.add("Java");
7: langs.add("Scala");
8: langs.add("Ruby");
9:
10: final String msg = "Got ya";
11: langs.each(new HandleAll() {
12: public void handle(String s) {
13: System.out.println(msg + ": [" + s + "]");
14: }
15: });
16: }
17:}
18:
19:class MyList extends LinkedList<String> {
20: void each(HandleAll handler) {
21: for (String s : this) {
22: handler.handle(s);
23: }
24: }
25:}
26:
27:interface HandleAll { void handle(String s); }
Back on 2004, Fowler said about closures:
So the first crucial point about closures is that they are a block of code plus the bindings to the environment they came from. This is the formal thing that sets closures apart from function pointers and similar techniques.(Java's anonymous inner classes can access locals - but only if they are final.)
As we can see on lines 10 and 13 our method being sent to the each operation is capable of accessing a local variable (marked as final though). Of course, closures should be much more easy to manually write, that's half of their strengh.
This is again, just to exemplify the concept, even so, anonymous inner classes are extremely handy in the absence of "normal" closures backed up by good syntax sugar.
(*) Extending LinkedList is not encourage, but this is just to make the example simpler
(**) In favour of Java I can say that free IDEs like Eclipse can generate all this verbose code with a few keystrokes (and programmers are more than used to that with their editors, hehe). Hence, leaving us the the best of both worlds, closures but still all the good side of static typing, like safe automated refactorings. And the chances you to be using already a IDE for Java development are rocket high...
(***) Closures are much more pleasant with proper syntax sugar, there's no way do deni it.
Comments
msgis final, you can't redefine it somewhere else.If 'msg' was an reference to an class instance than you could all sorts of updates to it, and work normally. If that was really an issue, a simple object with message as attribute would solve the case, just a few (really few) more lines.
Remember, java doesn't even let you change object references sent as parameters to any method, we are just used to do it locally afterall, or through 'setter' methods, what would bring us to a class instance whose only the reference would be final.
Thus, your example is not a closure because it's already a closed term, the compiler already knows what
msgrefers to.Of course, :-)
PS: I don't have yet this book, still trying to digest the Scala by Example and the Scalazine articles:
http://www.scala-lang.org/docu/files/Sc
http://www.artima.com/scalazine
But this is just a simple closure example. Doesn't it show the same concept of the java code on the post? It just changes the value of the local var... In my first reply I showed how this can be done in Java...
Some time ago I wrote some Ruby code with a closure that access 2 local string variables:
What was not clear to me was the concept of 'free/non-free variables' you mentioned, if non-free variables relates only to 'final' variables, could we simply call it constants? What in Scala can be defined with the 'val' keyword?
PS: I still think that the lack of changing references (memory pointer) to Java anonymous inner classes doesn't stop us to have all closures features, after all, all references to any java method are immutable from the caller perspective, so this would be no novelty. Although this can be easily bypassed with a small quantity of code, as you said 'a layer of indirection...' :)
MyList langs = new MyList() {{ add("Java"); add("Scala"); add("Ruby"); }};