On Tue, Apr 12, 2011 at 10:20 AM, Stephen Colebourne <[email protected]> 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 <[email protected]> wrote: >> On Mon, Apr 11, 2011 at 1:31 PM, Gary Gregory <[email protected]> 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: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
