commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Kestle (JIRA)" <j...@apache.org>
Subject [jira] Commented: (COLLECTIONS-233) Closure is an inaccurate name
Date Mon, 06 Nov 2006 09:54:40 GMT
    [ http://issues.apache.org/jira/browse/COLLECTIONS-233?page=comments#action_12447406 ]

            
Stephen Kestle commented on COLLECTIONS-233:
--------------------------------------------

"uneccessary code rework" is not really so significant if Closure still exists.  However,
on thinking, "Processor extends Closure" was for backwards compat.  In a new version (generics)
it would probably be "Closure extends Processor" so the deprecated interface is not everywhere.

Procedure sounds good to me; action not so good - Action.execute() does not not read too well.

Perhaps this may not be so much for lispers etc - it's just that I learnt a lot of good terminology
from using the collections package, and as far as I can see, this is the only problematic
interface - I had to look up this term, and then find that it's not appropriate.  It also
doesn't follow that apache should be messy just because the rest of java is inconsistent.

It doesn't really affect me in the end - I have my own interface that I use.  It's more for
completeness/the community.

> Closure is an inaccurate name
> -----------------------------
>
>                 Key: COLLECTIONS-233
>                 URL: http://issues.apache.org/jira/browse/COLLECTIONS-233
>             Project: Commons Collections
>          Issue Type: Improvement
>          Components: Collection
>    Affects Versions: Generics
>            Reporter: Stephen Kestle
>
> 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.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message