[ http://issues.apache.org/jira/browse/COLLECTIONS-233?page=comments#action_12447333 ] Holger Hoffstätte commented on COLLECTIONS-233: -----------------------------------------------
To this old Smalltalker "Processor" is IMHO not only very confusing (I immediately associate it with a CPU) but also sort of wrong: the block/closure/procedure/whateveryoucallit is not responsible for doing the actual processing (even though it ends up doing it); it is being "processed" or if you will "performed" on behalf of someone else. Action or Procedure (since it's void) would be much more appropriate. That being said, the notion that Lispers might be confused is a nonstarter because as far as I can tell they (just like most Smalltalkers) have completely given up on Java making sense anyway. There is really no value in renaming just for renaming's sake, especially considering that it will require unnecessary code rework without benefit. > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
