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 22:59:37 GMT
Matt Benson wrote:
>> 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.

Nope, just saying that [functor] looks finished as is, and could make a 
case for being proper separate to this discsssion.

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

Thats what I was driving at with this and the next section. In my time 
in [collections] I inherited the functor APIs. I always thought of them 
as slightly detached, but they had become inseparable from what 
[collections] is.

>  From whence did the bean-collections move?

The collections in [bean-collections] were formerly part of [collections].

We should be clear that there are no perfect solutions here. However, I 
will note that [collections] is too large a jar file in Kb for some 
people now.

 > As I see it, the functors in [collections] are a subset of those
 > in [functor].
Agreed. But the [collections] ones have more history and usage in user-land.

 > Presuming we allow both sets to stand, this still
 > does not address the concern voiced by James Carman:  a [functor]
 > UnaryFunctor--for any of which an analogous interface WILL exist in
 > [collections]--is not readily usable in [collections].  I still
 > don't see what the big deal is about optional dependencies, so can
 > we agree that [functor] could provide adapters to [collections]'s
 > functors when appropriate, creating an OPTIONAL dependency on
 > [collections] from [functor] (i.e. required only when the adapter
 > code is used)?

This is the deeper question, of which there is no perfect solution.

One approach is the optional dependency as described. The problem is 
that humans find this hard to grasp and dependency analysers don't 
follow it at all.

Another solution is to create a small binding jar [functor-collections] 
that links the two projects. This is clear to users and tools, but also 
a bit of a hassle.

Yet another solution is to copy the interfaces from [collections] into 
[functor] without changing the package names. This sounds mad at first, 
but has been done before with [beanutils]. The key point is that the 
original project has to commit to never change any aspect of the copied 
files, which in this case would be fine. The only downside with this 
approach is if [collections] and [functor] ended up in different 
class-loaders, because you'd then have two copies of the [collections] 
functors, one in the collections jar and one in the functor jar.

This final approach works in reverse, as I mentioned in my last reply. 
If [collections-ng] included the key [functor] APIs.

Overall though, I still haven't really seen a compelling argument as to 
why [functor] can't include collection implementations directly based on 
the JDK List/Set/Map interfaces (leaving any [collections-ng] without 
any functors or functor-based collections).


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

View raw message