>>>>> "Henri" == Henri Yandell <[EMAIL PROTECTED]> writes:
Henri> Been a while since the last one of these, so I expect a few
Henri> bits to be missing. Feel free to chime in on things I've
Henri> missed:
Henri> Next release will be Lang 2.0.
Henri> Lang 2.0 scope:
Henri> org.apache.commons.lang.functor.*
Henri> There is obviously a clash with Collections here, which
Henri> Lang seeks to
Henri> resolve. Also there is a clash with Rodney's [Functor]
Henri> package. From what I understand, despite the similar naming,
Henri> [Functor] goes a lot further into the concepts than .functor
Henri> does, with .functor being a simpler setup etc. I'm going on
Henri> hearsay though, not having looked at the code yet.
Dear All,
my opinion on lang.functor probably comes too late to have any impact on
the course of the release of Lang. But still feel the urge to express
my feeling that something goes into the wrong direction with lang.functor.
In my opinion lang.functor should not enter 2.0 in the current state:
The major issue which I have is the naming of the interfaces. While
names like "UnaryFunction" or "BinaryProcedure" may sound a bit esoteric
for the unaccustomed ear, these names do however expose the real nature
of the interface or their implementations.
- "Executor" is the interface for something which is executed not as the
name suggests something that executes. If renamed to
"UnaryProcedure", I would be able to grasp the nature of this
interface and its associated "Utils" class without refering to the
javadoc.
- While the notion of "Factory" is widely known and the nature
of this interface is well exposed by the class name, one may wonder
why a creational pattern like "Factory" is found in generic
functor package. The name Factory suggests that this interface should
only be used in Factory contexts. IMHO, "Function" (in the context
its of "Unary" and "Binary" counterparts.) is more general and allows
for the same purposes originally intended. The user programmer may
then "class WidgetFactory implements Function" or "class WidgetFactory
implements UnaryFunction" if the Widget creation should be
parameterized with one argument. How would we proceed in the future
if the names are not changed and we would like to introduce
parameterized Factories? UnaryFactory?
- "Predicate" is fine as a name.
- "Transformer" does imply an argument. But does it imply as well that
there is a result? Furthermore, the name somehow suggests that it is
to be used to 'transform' objects, which is in my experience never the
case: The argment object is usually left unchanged while a result is
calculated as function of the argument object. Wouldn't
"UnaryFunction" not be a more indicative name for this interface?
I believe that the names where chosen with the intent to gradually
remove the counterparts in Collections. However, currently there is no
dependence of Collections on Lang.functor, so renaming the interfaces would not
do any harm. Of course I aggree that the migration of Collections to
lang.functor would be quite smooth. However, in the longterm
Collections will have to live with the same naming problems as I have
described above.
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
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.
Cheers,
Arnd.
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 .
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]
