commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Colebourne <>
Subject [collections] New commons proper component - collections-functors
Date Tue, 29 Nov 2005 23:08:19 GMT
Phil Steitz wrote:
> -0 for following reasons:
> 1. I am having a hard time understanding what the value
> commons-functor by itself is going to be.  How do we expect it to
> "grow" - independently of collections - other than by replicating
> functionality in [functor]?
Functor in the sandbox may well be a better designed, purer functor 
library, but it has not seen any activity in a long time.

Collections functor package has had a number of proposed patches for new 
functors which I have had to reject as they bloat the collections jar 
file. As an independent jar file, only taken by those who want the 
collections functors, these new functors could be happily accepted.

> 2.  The small reduction in jar size for [collections] that may appeal
> to a small number of users might be cancelled by the annoyance of a
> possibly larger number of users who will have to change dependencies,
> classpaths, etc to add the new jar if they need it.
Currently, collections is 550K and almost certainly the largest 
sourcebase in commons. It must reduce in size. Period. Functors are the 
most consistently referred to item that could be removed.

Either a new component is created, or a new jar within collections is 
created. I believe that the latter hides what is going on.

> 3. Given the relatively tight coupling above, I don't see the
> rationale for creating a separate component.  If we want to ship
> [collections] in 2 or more jars (we already do that for the test
> framework) that is fine (modulo the inconvenience factor), but I don't
> (yet) see the need for creating another component.
Releasing multiple jars from one project is actually quite nasty. (for a 
start you can throw maven out). More significantly, it just hides the 
functionality. BTW, this isn't new - [primitives] is exactly the same as 
what we are discussing here.

> 4. This adds intra-commons dependencies, which I have come to agree is
> not a good idea, especially for widely used base components such as
> [collections].  Allowing [collections] and [collections-functor] to
> release independently is asking for the problems associated with these
> dependencies.
The dependency is from [collection-functor] two four interfaces in 
[collections]. These interfaces have not changed since they were 
originally released, and will not change. It would even be possible to 
include the interfaces in the [collection-functor] jar and have no 

> 5. (could be viewed as expansion of 1)  I don't like the idea of
> promoting a bare-bones functor library when we have a much more fully
> functional one in the sandbox.  Though my French is a little rusty, I
> like Robert's idea of a "portmanteaux" and would like to think
> carefully about that option before creating a functor component
> completely independent of [functor].
[sandbox-functor] has *nothing* in common with [collection-functor]. Nor 
is it going to. The source and approaches are just different.


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

View raw message