commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arnd Kohrs <ko...@castify.net>
Subject Re: [lang] scope for version 2
Date Mon, 24 Mar 2003 10:26:31 GMT
>>>>> "Henri" == Henri Yandell <bayard@generationjava.com> 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message