commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From François LEIBER (JIRA) <j...@apache.org>
Subject [jira] Commented: (COLLECTIONS-233) Closure is an inaccurate name
Date Mon, 07 Sep 2009 08:55:57 GMT

    [ https://issues.apache.org/jira/browse/COLLECTIONS-233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12752052#action_12752052
] 

François LEIBER commented on COLLECTIONS-233:
---------------------------------------------

I also vote on the "Won't fix", Closure doesn't sound so bad.
And no, now that JDK7 is arriving, we know closures won't be included in it.

> Closure is an inaccurate name
> -----------------------------
>
>                 Key: COLLECTIONS-233
>                 URL: https://issues.apache.org/jira/browse/COLLECTIONS-233
>             Project: Commons Collections
>          Issue Type: Improvement
>          Components: Collection
>            Reporter: Stephen Kestle
>             Fix For: Generics
>
>
> 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.

>  
> From http://en.wikipedia.org/wiki/Closure_(computer_science): 
> 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: 
> calculate(uri); 
> // It can access private fields of the enclosing class: 
> btnSave.setEnabled(true); 
> } 
> }; 
> 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.  It is not actually possible to
have a "Closure" object, as that breaks the lexical environment.
>  
> 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 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. 
>  
> For backwards compatibility the interface would be  
>         public interface Processor<T> extends Closure<T>{} 
> with the appropriate documentation.   Closure would be deprecated with an appropriate
explanation. 
> However, it may be acceptable with the new version just to do a rename.
>  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message