Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (nike.apache.org: domain of gudnabrsam@gmail.com designates
 74.125.82.49 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:reply-to:in-reply-to:references:date:message-id
         :subject:from:to:content-type:content-transfer-encoding;
        b=J+2dFvBJ/1PCX7zmCey7caBRqU3YsJVYuu9W6fd+SACc5nLr0u+T+p4LghTEmD3OvJ
         ABb+s+xluyHklo9vi6O9Hr7VztauY/FGm6wzbhbFbMGr0EeCGCeVW8UEvjnCwibwAJ1c
         slC9AHCRd8u+pq3qmqeBIqOoYSm55e8SsCUgo=
MIME-Version: 1.0
Reply-To: gudnabrsam@gmail.com
In-Reply-To: <BANLkTi=zadUa98AHSxLgQwney89HZ1CDgA@mail.gmail.com>
References: <BANLkTi=Hzne_mSrqwtc0_ePzM7YhKNRe0g@mail.gmail.com>
	<BANLkTi=DyWNLst+QHWukFohLa_34Q-+GJw@mail.gmail.com>
	<BANLkTi=zadUa98AHSxLgQwney89HZ1CDgA@mail.gmail.com>
Date: Tue, 12 Apr 2011 11:10:39 -0500
Message-ID: <BANLkTikrb2Kt8HKJdwc5q8K-_u2ZmB2qTw@mail.gmail.com>
Subject: Re: [lang] Pair vs. [collection]
 org.apache.commons.collections.keyvalue
From: Matt Benson <gudnabrsam@gmail.com>
To: Commons Developers List <dev@commons.apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Tue, Apr 12, 2011 at 10:20 AM, Stephen Colebourne
<scolebourne@joda.org> wrote:
> The [collections] KeyValue class was a mistake. [lang] Pair is a
> better more general concept.
>
> The only thing I'd consider with [lang] Pair now is whether it should
> move to its own package, in case it grows later (primitive versions).
>

oacl.tuple?

Matt

> Stephen
>
>
> On 11 April 2011 21:00, Matt Benson <gudnabrsam@gmail.com> wrote:
>> On Mon, Apr 11, 2011 at 1:31 PM, Gary Gregory <garydgregory@gmail.com> w=
rote:
>>> Hi All:
>>>
>>> I am now realize that what we are stumbling along with Pair has already=
 been
>>> done in org.apache.commons.collections.keyvalue, generics and all. Diff=
erent
>>> class names but the same ideas.
>>>
>>> So... it sure would be nice to avoid creating the same thing in [lang] =
but
>>> with different class names.
>>>
>>> What are our options:
>>> - Continue blindly
>>> - Converge both components on the same class names. [lang] has 3 classe=
s,
>>> [collections] has 8.
>>> - Drop Pair in favor of org.apache.commons.collections.keyvalue.
>>>
>>> I feel we need a good story here before releasing 3.0 with 3 new Pair
>>> classes.
>>>
>>> Thoughts?
>>
>> Remember that Pair, as originally added to the [lang] codebase, did
>> not implement Map.Entry, nor did it support mutation, and that, being
>> immutable, it didn't even provide accessor methods. =A0It was the
>> simplest 2-valued tuple, or "pair", as was possible. =A0It was only at
>> others' insistence that I modified the design to what currently
>> resides in trunk (I would personally shed no tears over reverting back
>> to the original code). =A0The generics branch of [collections] may or
>> may not ever see release, but even assuming it will eventually do so I
>> don't find it an unreasonable proposition that [lang] provide
>> something so simple as a Pair. =A0In fact it makes perfect sense to me
>> that the most-often used ancillary classes of other Commons components
>> eventually find their way into [lang], whose mission it is to provide
>> those indispensible items missing from the core APIs. =A0Conversely, the
>> argument could be made that providing a KeyValue class with no
>> collection- or map-related ideology attached is a case of
>> [collections] overstepping *its* bounds. =A0In the end, [collections]
>> and [lang] are "core" enough extensions that neither should depend on
>> the other, even if that means they overlap a little at the edges.
>>
>> $0.02,
>> Matt
>>
>>>
>>> --
>>> Thank you,
>>> Gary
>>>
>>> http://garygregory.wordpress.com/
>>> http://garygregory.com/
>>> http://people.apache.org/~ggregory/
>>> http://twitter.com/GaryGregory
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

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