commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rodney Waldhoff <rwaldh...@apache.org>
Subject back to functors (was Re: [general][lang] monolithic components considered harmful)
Date Thu, 02 Jan 2003 23:38:27 GMT
On Wed, 1 Jan 2003, Costin Manolache wrote:

> If you define "functor" the way Craig did - an interface that
> could be used as a common hook mechanism - I would gladly change my vote
> to +1.
>
> And it will be: "if you want a hook mechanism, use commons-functor"

I would have phrased it as "if you want to treat functions as objects",
but I think we're largely talking about the same thing.  Being able to
"plug in" a new function by registering an "extension point" or passing in
a "callback" method are an examples of treating functions as
objects--i.e., they rely upon being able to pass around references to
functions the way Java supports passing around references to objects.

> There are few requirements I have:

This won't be fully determined by me of course, but...

> 1. You must be well aware that this is an interface package.

This is very much an interface package.  One could easily imagine a core
distribution containing nothing but interfaces and simple adapters between
those interfaces (e.g., something that turns a Predicate into
Boolean-returning Transformer, or vice versa).

> It just won't work with 3 +1 votes as a regular commons interface.
> You need buy-in and participation from significant apache projects.

To be considered successful, [functor] should be used and/or supported by
other projects (apache or other).  The same is true for most if not all
commons components.

> 2. It shouldn't get too much into implementing functors, just define
> the interface and tools ( and maybe wrappers for existing hook
> mechanisms ).

Agreed. I imagine functor containing only the interfaces and the most
basic implementations and adapters.  One can imagine the possibility of
add-on components that implement a non-trivial collection of functors for
some specialized purpose but that's a topic for another discussion and
other proposals.

> 3. It should be able to support existing patterns:

> - iterative invocation of functors as well as recursive (
> valve/interceptors:-)

I would expect support for, as Craig and Tom discussed, the composition of
functors and the chain of responsibility pattern, as well as things like
strategy, visitor (with support from the component defining the structure
being iterated over, e.g., collections), variations on template method
(using composition rather than inheritance), etc.  Indeed many of the GoF
"behavioral" patterns seem to apply, extend or suggest the functor idiom.

> - JDK1.1 compat ( so it could be used someday in Ant ).

I also imagine that the core interfaces and most if not all basic
implementations wouldn't need anything not found in JDK 1.1.

> This must be config-neutral and support regular bean patterns ( so
> it can be managed by modeler and integrated in existing apps ).

I would expect most if not all of [functor] to be not just config-neutral,
but config-free.

> I also have a problem with the name "functor". I would rather have
> "callback", "hook", "extension point", "plugin" ( if this is what you
> have in mind ).

I believe "functor" to be a less ambiguous label for this component than
something like "plugin" or "callback", but frankly if that's the
difference between moving forward with [functor] or not, I'd be open to
alternatives.

> In other words: one hook mechanism to rule them all :-)

I'm not interested in ruling anything, although "one hook mechanism usable
by all" sounds admirable enough.  More than anything what I'd like to see
is a world where simple functor and functor-based utilities are
interoperable, so that, for example, if [io] (or [io-functors] or
[functors-io] or whatever) implements IsDirectoryPredicate and
[collections] implements PredicateIterator, I can put the two together to
iterate over the directories in a List of Files.  And where I can do this
without caring about the release status of EnumUtils or DoubleRange.

 - Rod

> Costin


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message