commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <>
Subject Re: [lang] Pair vs. [collection] org.apache.commons.collections.keyvalue
Date Mon, 11 Apr 2011 20:00:02 GMT
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.


> --
> Thank you,
> Gary

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

View raw message