commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rodney Waldhoff <rwaldh...@apache.org>
Subject Re: [collections][lang] Functors, pre-vote
Date Mon, 09 Dec 2002 12:28:20 GMT
On Sun, 8 Dec 2002, Stephen Colebourne wrote:

> From: "Rodney Waldhoff" <rwaldhoff@apache.org>
> > On Sun, 8 Dec 2002, Stephen Colebourne wrote:
> > > Solution #3 [functor] project, that contains the functor interfaces,
> > > implementations and 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.
>

You're right, the Functors-acting-on-Collections methods don't need
commons-collections, just java.util.  This has an added benefit of making
the transition from [collections] to [functor] easier for us to deal with.
We don't need to update anything in [collections], we just need to remove
things.  We could deprecate the [collections] versions and keep them
around (otherwise unchanged) for several releases if we wanted, both
versions (even the already released versions of [collections]) should work
in parallel just fine.

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

I think I'm liking that approach more and more.

 - Rod

> Stephen


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