commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <>
Subject Re: [collections][lang] Functors, pre-vote
Date Sun, 08 Dec 2002 21:56:53 GMT
From: "Rodney Waldhoff" <>
> On Sun, 8 Dec 2002, Stephen Colebourne wrote:
> > Solution #3
> > [functor] project, that contains the functor interfaces, implementations
> > CollectionUtils implementations, with the collections interfaces and
> > CollectionUtils code deprecated in favour of the functor ones.
> In this scenario, why would the CollectionUtils methods need to be
> removed? (They'd need to be changed to use the [functor] project's
> packaging of Transformer, Predicate et al of course.)  It makes sense to
> me to have [functor] define the core interfaces (and where appropriate,
> implementations), and still leave the CollectionUtils methods as functors
> applied to collections.

The reasoning is to allow [collections] to remain dependency free. I also
think that its not a bad idea to put the code where functors operate on
collections in [functor] - those methods only require the JDK collections
interfaces to work ;-) Basically, functors operating on collections _could_
be in either component, but by being in functor the dependency is removed.

> > - [functor] depends on [lang]
> The o.a.c.lang.functor package is only weakly coupled with anything else
> in o.a.c.lang:
> a) the Exception classes extend NestableException, which simply dulicates
> functionality already available in 1.4 VMs (and not all that elegantly
> since the API is different from that in 1.4)
> b) FactoryUtils uses a single, simple method of SerializationUtils to
> perform a serialize/deserialize copy.

Hmmm, this opens up the possibility of three non-dependent components which
would be good I suppose.

(I guess this in solution #6)

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message