[jira] Commented: (COLLECTIONS-233) Closure is an inaccurate name

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

[jira] Commented: (COLLECTIONS-233) Closure is an inaccurate name

JIRA jira@apache.org

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

Brian Egge commented on COLLECTIONS-233:

In some future version of Java, we may get Closures.  It hasn't been voted into 7.0 yet.  I think the Closures offered by the Collections is currently the closest thing you can get in Java.  True, it not a real closure like what you get in Smalltalk or Ruby.  Having learned to use Closures in Ruby, I found it easy to pick up in the Collections framework.  Having another name would make the process more complex.  If/when Java comes up with real closures, we could depreciate the Closures interface, and give a good example of how to convert it to a real one.

Introducing the Processor interface, would just create additional refactoring, if the end goal is to use a built in Java mechanism instead.  

I vote "won't fix" on this issue - at least not for now.  Maybe if the 1.4 branch was in depreciated status, and there was a clear idea of if Closures are going to be introduced into the Java languages, and if they are, what exactly the usage is going to be.  (As I understand there are two competing ways of implementing closures).

> 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.