commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Colebourne <scolebou...@joda.org>
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).

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


Mime
View raw message