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] Functor debate
Date Mon, 24 Mar 2003 15:41:53 GMT
>>>>> "Stephen" == scolebourne  <scolebourne@btopenworld.com> writes:

    >> from: Arnd Kohrs <kohrs@castify.net> 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

    Stephen> You are correct in your evaluation that the names chosen do
    Stephen> not allow for other later functions, such as Binary or
    Stephen> no-argument forms. They are instead chosen to be simple.

I don't agree that the current names chosen in lang.functor are simple,
and provided arguments for it in my first post (which you dit not
respond to).  I do not make this up: When I read about a lang.functor
package to be included in 2.0, I checked it out, and was as confused
when I browsed over the class names, as people would be about the other
functors when first encountering.  I needed to look-up for example
"Factory" and then mapped it in my mind to no-arg function.  Factory by
itself does not sufficiently explain its nature.

To put it differently, I suggest a "renaming" refactoring because the
current naming is not indicative enough nor coherent.

    Stephen> My rule of thumb is [lang] simple, other project ([functor]
    Stephen> in this case) higher level/more complex. You're never going
    Stephen> to convince me that 'BinaryPredicate' is simple in concept
    Stephen> even if it is the formal computer science solution.

IMHO it does not serve a rational evaluation of my proposal to choose
'BinaryPredicate' as an example 
 - which I did not suggest to be added to lang.functor (only as a
   possibility).  The addiction of binary functors to lang is not
   important now.
 - and which does not have a lang.functor counterpart in the current
   lang.functor package:
   Obviously it is not as simple as a NON-existing concept.

    >> 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 .

    Stephen> Yes I've taken a look before, and the concepts seem
    Stephen> sound. However, it requires you to invest more effort in
    Stephen> learning the framework and its intracies - it is more
    Stephen> complex. As such I know that I would not choose to use the
    Stephen> complex functors. Whereas I find those in [lang] simpler,
    Stephen> if less flexible. Everythings a tradeoff ;-)

I find it easier to adopt a conceptual framwork which has a coherent
naming convention.  There is not coherence in "Executor", "Transformer",
"Factory" and "Predicate" although the coexitence of in the same package
would suggest so.

All which needs to be understood if these functors where renamed
following the naming which are customary in functor libraries and
which I referred to, is founded on two orthogonal concepts:

1. Functor Types
- Function: Functor which has a result
- Predicate: Functor which has a boolean result
- Procedure: Functor which has no result

2. Number of Arguments
- *Unary*Functor: one argument functor
- *Binary*Functor: two argument functor
- Functor: (Null-ary) no argument functor

Once these two axises are understood there is no need to provide extra
explanation for instances of Functor interfaces in this space.  This is 
not the case for, Factory, Transformer and Executor.  

Example BinaryPredicate: is a Functor with a boolean result which has
two arguments.

It is not necessary to understand possible extensions of this concept,
e.g. internal iterators or functor composition.  At least not more as if
one wanted to use "Transformer".

For Lang2.0 I would only go as far as limiting functors to Null-ary and Unary
functor interfaces, as there currently seems to be no need for Binary
functors. 

I see the lang.functor as a light-weight place for standardizing
interfaces of functors.  Then other components may provide internal
iterators or related interfaces based on lang.functors such as
Collections.  And functor utility components may provide the
compositions and default implementations using the same functor
interfaces which are defined in Lang.

If lang cannot provide a functor package which may be used as a standard
or if this is out of the lang scope, the incoherent current approach to
functors may discourage the evolving and adoption of a functor component
with a broader scope.  Therefore, without modifications, I would opt for
dropping functor from lang, and leave the rudimentary functor stuff in
collections, as the lang package does not aim for a broader scope.

Please take no offense in my argumentation.  I know that a lot of people
have strong feelings about functors and I am one of them.

Cheers,
Arnd.




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