commons-dev mailing list archives

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

From: John Bollinger <thinman42@yahoo.com>
> 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:
http://commons.apache.org/collections/api-release/org/apache/commons/collections/package-summary.html
http://commons.apache.org/sandbox/functor/apidocs/org/apache/commons/functor/package-summary.html
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
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.

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

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

Stephen

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message