Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of phil.steitz@gmail.com designates
 64.233.162.194 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=JHTTWFCIJ3SNBFO02WuqTNDlQYN/Hqit/6HR/fre07gJrjmrFPrumePD34LEqke0ma6Gi7uEql3S+Jd4kBPj0prv0aU2mBihYg0kkrRIjfFo0Q3vkgxV0gRTNqkBbe3MtvxwwcrfuQSICF54twxwbob71EzN7fVLdAoc/T+x1tE=
Message-ID: <8a81b4af0511281838p23f26f48r6434ab52929c4558@mail.gmail.com>
Date: Mon, 28 Nov 2005 19:38:52 -0700
From: Phil Steitz <phil.steitz@gmail.com>
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: Re: [VOTE] New commons proper component - collections-functors
In-Reply-To: <438BAB9C.5050202@btopenworld.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <000a01c5f473$a1b44710$7f53058f@CARMANI9300>
	 <438BAB9C.5050202@btopenworld.com>

On 11/28/05, Stephen Colebourne <scolebourne@btopenworld.com> wrote:
> James Carman wrote:
> > So, TransformerUtils would have to move into the new component, right?
> > Would the Transformer, Closure, and Predicate interfaces stay in the co=
re
> > package or go into the new component?
>
> TransformerUtils -> [collection-functors]
> PredicateUtils -> [collection-functors]
> ClosureUtils -> [collection-functors]
> FactoryUtils -> [collection-functors]
>
> Transformer -> [collections]
> Predicate -> [collections]
> Closure -> [collections]
> Factory -> [collections]
>
> Stephen

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

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.

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.

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.

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

Phil

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