commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Colebourne <>
Subject Re: [lang] Pair vs. [collection] org.apache.commons.collections.keyvalue
Date Tue, 12 Apr 2011 15:20:10 GMT
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).


On 11 April 2011 21:00, Matt Benson <> wrote:
> On Mon, Apr 11, 2011 at 1:31 PM, Gary Gregory <> wrote:
>> 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. Different
>> 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 classes,
>> [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.  It was the
> simplest 2-valued tuple, or "pair", as was possible.  It 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).  The 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.  In 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.  Conversely, 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.  In 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
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message