commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [lang] Functor debate [was re: [lang] scope for version 2]
Date Mon, 24 Mar 2003 13:46:03 GMT
>  from:    Arnd Kohrs <>
> I suggest to do the following renamings in for Lang 2.0:
> - Executor    --> UnaryProcedure
> - Executor.execute(..)    -->
> - 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
> . 

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 ;-)


> 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:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message