With the recent revival of adding closures to Java, I came across the post by Stephen Colebourne that contained an updated version of his comparison table (which appeared earlier in his ‘Comparing ‘closure’ proposals’ post). The list contained some items that weren’t immediately clear to me, so I went ahead to attempt to attach a description to each of them.
Literals for reflection
Instead of using Strings and reflection to create a reference to a method or field, reflection literals would allow you to directly refer to a method. One of the benefits is the possibility of compile-time checks.
Method references
The above reflection literals allow for references to existing methods, which can then (easily) be passed around and called.
Closures assignable to single method interface
This allows a closure to be assigned to a variable whose type is an interface with a single method. This would eliminate the verbose syntax currently used to create an anonymous inner class with a single method, like a Runnable or ActionListener.
Closures independent of single method interface
Having closures independent of a single method interface allows the creation of closures without the need for an interface to exist.
Access non-final local variables
With inner classes, one cannot access local variables (variables local to the method that defined the inner class). Being able to access and modify non-final local variables gives more flexibility.
Keyword ‘this’ binds to enclosing class
With inner classes, ‘this’ binds to the instance of the innerclass. Most proposals agree that ‘this’ will refer to the enclosing class.
Local ‘return’ (binds to closure)
This means that a return statement within a closure will return from the closure and continue from the location where the closure was called.
Non-local ‘return’ (binds to enclosing method)
In contrast to the local return, the non-local return would return from the defining method. In a situation where the closure blends in with the rest of the code, as in control structures, this makes a lot of sense but the BGGA proposal is the only one proposing this. It has some issues when the method containing the definition has already exited.
Alternative ‘return’ binding (Last-line-no-semicolon)
Complements the previous item: if the default is a non-local return, then this would allow one to return a value from a closure.
Exception transparancy
When an exception is thrown from a method, it needs to be defined. For closures this would either require function types or interfaces to specify the exceptions that can be thrown from the closure, or the exception to be handled/converted within the body of the closure. By having exception transparency the exceptions need not be defined beforehand, and can be handled by the code calling the closure.
Function types
These are used to be able to assign a closure that is independent of an interface to a variable.
Library based Control Structure
This means that control structures, such as the enhanced for loop, can be added as a library, instead of modifying the language.
Personal blog on my interests.
| Sun | Mon | Tue | Wed | Thu | Fri | Sat |
|---|---|---|---|---|---|---|
| << < | Current | > >> | ||||
| 1 | 2 | 3 | 4 | 5 | ||
| 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 13 | 14 | 15 | 16 | 17 | 18 | 19 |
| 20 | 21 | 22 | 23 | 24 | 25 | 26 |
| 27 | 28 | 29 | 30 | 31 | ||