This Runnables would be executed when the paint, load, etc. events were triggered.

The result was that none of the shortcomings that you mention were real problems.

The only annoying problem was having to write the whole Runnable. It would be easier if you only had to write something like f.onPaint( #{ object.doSomething(); } ).

The other problems I find in Java and that C++ already had solved were:

1. Destructors. In C++ you declare the destructor and you forget about it. Not so in Java, you have to use finally everywhere. It is not pretty.

2. The lack of operators. Syntactic sugar, yes. But necessary sugar.

thank you very much for your critical comments!

>> … anonymous methods require variables to be made final as its probably the easiest problem to get around.

First of all, the post is mainly about an experiment about how ‘concise’ and ‘readable’ you can get with the given language features. It’s a fact, that you only can refer to final variables, since they end up on the Heap – nothing more, nothing less (if it seems that i was mainly complaining about this fact, it’s rather my fault not to make things clear enough).

>> … does nothing to reduce the clutter that defining an anonymous class requires (compare your definition with the BGGA equivalent, {int a, int b => a*b}

Yes, as said in the post – it’s at least an experiment to become as concise as possible with the given features. It’s of course much more bloated compared to BGGA, but in my opinion more concise (i’m not saying by a huge amount) than implementing an Interface while repeating the whole signature of a method all over again.

Of course (again mentioned twice in the post), it’s by far not as powerfull as Closures (i.e. the post doesn’t mention issues with stateful classes and concurrency, exceptionally escaping from Closures, … ), however could it serve for a good part of problems that are now tried to be clobbered by Closures.

>> And I’m not too happy with the practice of defining an entirely new package for every conceivable number of argument parameters (exactly how high are you planning to go?)

As explained in the post – for providing Block classes for a maximum number of say five arguments (seriously, did you use more than three or four arguments in practice?) – exactly five classes. Nothing more, since they are Generic, so you can use every combination of types with the given classes!

>> thats what arrays are for (if you don’t like the syntax of defining an array, use the Java 5 var args to do it)

I don’t get your point about this part. If you want to forgo a type safe way of using arguments of potentially different types (since you can’t declare an array of different types you have to use the most abstract type of Object), go on. But than the resulting block definition is again bloated by some casts. Nothing about that – personally, i prefer a type safe way with the advantage to directly calling the given methods on that type within the blocks definition.

Greetings

Mario

thanks for your feedback. As pointet out in the post, the presented experiment is by far not comparable with the full power of Closures.
One thing, just indicated in the post, is the ability to access the lexical scope within the Closure was defined, even if that scope doesn’t ‘exist’ any longer when the Closure gets executed (as mentioned, only possible with final variables in Java).
Another essential function is the possibility to curry a given Closure (you may want to search for that idea, since it would take a little bit longer to explain).
That said, the demonstrated thoughts are by far not comparable with full featured Lambda calculus nor with Closures inherently.

Greetings

Mario

Yes, we get that closures technically can be done with the current Java spec. But it requires so much work to make it happen and is so ugly and unmaintainable that it is rarely used, which is going to be problematic as new structures such as the Java 7 fork join get added.

And I’m not too happy with the practice of defining an entirely new package for every conceivable number of argument parameters (exactly how high are you planning to go?), thats what arrays are for (if you don’t like the syntax of defining an array, use the Java 5 var args to do it). And the practice of naming a class with a lower case letter isn’t much better.

If we can do something like this in Java already, why do we need closures? Just to make it look better?