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