On Sun, 8 Dec 2002, Stephen Colebourne wrote: > From: "Rodney Waldhoff" <[EMAIL PROTECTED]> > > 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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
