commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <>
Subject Re: [all] Core library dependencies [was COLLECTIONS 3.3 release]
Date Tue, 12 May 2009 13:40:03 GMT

--- On Tue, 5/12/09, Stephen Colebourne <> wrote:

> From: Stephen Colebourne <>
> Subject: Re: [all] Core library dependencies [was COLLECTIONS 3.3 release]
> To: "Commons Developers List" <>
> Date: Tuesday, May 12, 2009, 6:29 AM
> From: John Bollinger <>
> > Which is exactly why Collections should not copy
> Functor.  Either Functor
> > should be absorbed back into Collections, or
> Collections should have
> > Functor as a dependency, for otherwise users must
> maintain separate
> > functors for use with Collections and for other
> purposes. Users of both can
> > rely on the Collections functors for everything, but
> that de facto rolls
> > Functor into Collections for them.  It also
> obligates them to adhere to that
> > approach, which has great potential for integration
> pain.
> >
> > A key issue here is that parts of the Collections
> public API reference
> > classes / interfaces of Functor.  Collections
> therefore must either own Functor
> > or depend on it.  There is no reasonable way to
> split the two projects without
> > making one depend on the other.  This is
> different from the case in some
> > Commons projects where classes are copied from another
> Commons
> > component for private, internal-only use.  Note
> also that the same argument
> > applies to moving the functor-based collections to
> Functor: then Functor would
> > need to have Collections as a dependency.
> The 'functors' in [collections] and [functor] are very
> different:
> There is no need to share these interfaces, add
> dependencies or anything similar. (Equally, were they the
> same John's argument would be sound.)
> What [functor] needs is the confidence to stand up and say
> "hey, come and use me, here's what I offer".

I somewhat resent the implication that I and others might be trying to buffalo [functor] into
"proper" status, but I'm known for paranoia, so forgive me if I've read more into that statement
than was intended.

> There is good
> stuff in [functor], but critically it is a semi-religious
> approach to coding.
> By this, I mean that developers have to "buy-in" to the
> idea that writing and using lots of small inner classes in a
> compositional fashion is what they want. And exactly in the
> same way as many developers don't like functional
> programming, many won't like the [functor] approach.
> That doesn't make it bad or wrong, it just means that it
> needs to stand up and own its own space. Users should want
> to use [functor] for what it offers. They need to make a
> positive choice.
> Now look at the other angle - what do users of
> [collections] want? Its additional implementations of JCF
> collections, and new related collection interfaces. In many
> ways, its a historic oddity that [collections] has any
> functor-like stuff at all. Many (most) users of collections
> are not interested in the functor-type stuff I'd suggest.

IMO this sounds like a reason to remove functor concerns from [collections] entirely.

> My strong recommendation is to add key collection classes
> to [functor] (directly implementing the JDK List/Set/Map
> interfaces). They differ from those in [collections] because
> the API of Predicate/Function etc is so different. Then
> promote [functor] to commons-proper with no dependencies.
> Then, [collections] can, over time, consider if it wishes
> to deprecate and remove its own functor based collections in
> favour of those in [functor], without ever needing a
> dependency beyond the JDK. This is exactly how the bean
> sytle collections were moved out to [bean-collections].

I wonder if it's worth the effort to maintain three jars for [beanutils] so  that users can
use split jars of a six-class difference when the dependency is still optional even when using
the complete jar.  But perhaps this is valuable when using dependency analysis of bytecode;
not being a user of such tools I wouldn't know.  From whence did the bean-collections move?
 [collections]?  Otherwise the analogy seems a little off.

> BTW, [collections] does publish a test-framework jar that
> [functor] could depend on as a test-only dependency.



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


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

View raw message