commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Colebourne <>
Subject Re: [all] Core library dependencies [was COLLECTIONS 3.3 release]
Date Tue, 12 May 2009 11:29:38 GMT

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

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.

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

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

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


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

View raw message