> from: Arnd Kohrs <[EMAIL PROTECTED]> > I suggest to do the following renamings in for Lang 2.0: > > - Executor --> UnaryProcedure > - Executor.execute(..) --> UnaryProcedure.run(..) > - Factory --> Function > - Factory.create() --> Function.apply() > - Transformer --> UnaryFunction > - Transformer.transform() --> UnaryFunction.apply(..) > - rename all the Utils classes accordingly > > - possibly complement with missing interfaces: > - Procedure > - UnaryPredicate > - possibly add BinaryPredicate, BinaryProcedure, BinaryFunction
You are correct in your evaluation that the names chosen do not allow for other later functions, such as Binary or no-argument forms. They are instead chosen to be simple. My rule of thumb is [lang] simple, other project ([functor] in this case) higher level/more complex. You're never going to convince me that 'BinaryPredicate' is simple in concept even if it is the formal computer science solution. > Then in the future the functor component (currently in Sandbox) may grow > up as a place for more advanced functor stuff (also to complement > collections) based on the interfaces provided in lang.functor. > > Of course, these proposals look like major changes right before a > release. And performing major changes right before a release is very > risky and should be avoided. However, while the changes seem major, > they are only "renaming" refactorings which could be implemented quickly > without changing any algorithms or functionality. If the lang.functor > is not improved now before the Lang2.0 it may never be improved and > collections will always rely on questionably named interfaces and > probably Collections will never live up to its opportunities. [functor] appears to be adding this kind of functionality, and as such should also add the corresponding collections utilities. > PS: Please have a look at commons-sandbox-functor. Further, if you have > some time at hand to get inspired about functors read > http://c2.com/cgi/wiki?BlocksInJava . Yes I've taken a look before, and the concepts seem sound. However, it requires you to invest more effort in learning the framework and its intracies - it is more complex. As such I know that I would not choose to use the complex functors. Whereas I find those in [lang] simpler, if less flexible. Everythings a tradeoff ;-) Stephen > PPS: Please excuse if I have tripped over some jakarta rules and > regulations. I have only been following jakarta commons for a several > months and may not be well accustomed to jakarta release interaction > protocols. > > PPP: I would of course volounteer to implement the suggested changes > myself, I they were generally aggreed upon. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
