commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [collections] New commons proper component - collections-functors
Date Wed, 30 Nov 2005 02:38:37 GMT
Thanks, Stephen.  While I still think 1, 5 are problematic, your
responses to the other points are enough to move me to +1

Phil
On 11/29/05, Stephen Colebourne <scolebourne@btopenworld.com> wrote:
> 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
> dependency.
>
> > 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.
>
> Stephen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>

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


Mime
View raw message