commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@btopenworld.com>
Subject Re: [lang] Functor debate
Date Tue, 25 Mar 2003 00:43:27 GMT
From: "Arnd Kohrs" <kohrs@castify.net>
> >>>>> "Stephen" == scolebourne  <scolebourne@btopenworld.com> writes:

(My short responses are due to time pressures...)

> Arnd:
> 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.
> <snip>
> 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.

The coherence is that they are basic callback interfaces. The name functor
has been used, however this package should never attempt to be a full
implementation of functor concepts or to include the work of [functor]. Its
about standardising some very common callback interfaces, and providing
implementations of those that can be shared.

Are they named correctly? Well perhaps Factory could be called Creator, as
this would be in line with the create() method. But otherwise I'm happy.


> 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

I don't dispute that this is the 'correct' or 'right' design for a full
functor implementation. However this is very much bigger in concept, and in
'religion', than [lang] could support or would wish to. [lang]s functors do
not have this goal - they aim to be simple commonly used callback
interfaces.

What I am arguing is that you may be reading too much into the word
'functor' in the [lang] context. What you are arguing for is [functor],
which is fine if thats what you want to use.

Stephen


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