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
