commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Kestle <>
Subject Closure is a really bad name
Date Thu, 08 Jun 2006 23:29:03 GMT
The "Closure" in commons collections is not named well: for 
non-functional programmers it will induce a "what's that?", and for 
functional programmers it will confuse expectations. 
A closure combines the code of a function with a special lexical 
environment bound to that function (scope). 
Java cannot pass functions, so the only way this can be done is with an 
(inner) class, as follows (also from wikipedia): 

class CalculationWindow extends JFrame {
     private JButton btnSave;
     public final calculateInSeparateThread(final URI uri) {
         // The expression "new Runnable() { ... }" is an anonymous class.
         Runnable runner = new Runnable() {
                 void run() {
                     // It can access final local variables:
                     // It can access private fields of the enclosing class:
         new Thread(runner).start();

Note how the Runnable accesses the btnSave variable in the function 
scope. This "special lexical environment" is NOT the same as passing a 
parameter through a constructor OR execute method. A Closure should NOT 
take a parameter for execute. AFAIK, a true Closure can only be 
implemented in Java by means of a non-static inner class.

See also, and for (IMHO) 
understanding and mis-understanding of closures in java.
So, what to do? 
I would propose an interface called Processor. It is more intuitive and 
has many "real world" examples that can anchor the term so that it makes 
sense to the average (and functional!) programmer. 
For example, when applying for a passport, some documentation needs to 
be filled out, and then it will go through a process to get you a 
passport. You hand (or send) your forms to a clerk (Processor), and 
that's it. The Processor does not reply - the context that is passed in 
your form (your details) allows a message to be sent back at a later date. 
My proposed class would be  
public interface Processor<T> extends Closure<T>{} 
with the appropriate documentation.  
Closure would be deprecated with an appropriate explanation. (I would 
advocate removing it by 2008, or when the Java "standard" is Java 5 
instead of Java 2)


Stephen Kestle

PS. Apologies if this topic has been covered before - I didn't see a 
search on the mailing list archives...

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message