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 <gudnabr...@gmail.com> wrote: > On Mon, Apr 11, 2011 at 1:31 PM, Gary Gregory <garydgreg...@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-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
