commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@gmail.com>
Subject Re: [lang] Pair vs. [collection] org.apache.commons.collections.keyvalue
Date Tue, 12 Apr 2011 16:10:39 GMT
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> 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
>
>

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


Mime
View raw message