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. > - [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. It would not be strictly necessary for [functor] to depend upon [lang], and this would remove the following drawbacks as well: > - Functor users, like [io], need to depend on [functor] and [lang] > - Causes problems if [lang] wants to use a functor -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
