On Wed, May 4, 2011 at 12:45 PM, Gary Gregory <garydgreg...@gmail.com> wrote: > On Wed, May 4, 2011 at 1:04 PM, Stephen Colebourne > <scolebou...@joda.org>wrote: > >> On 4 May 2011 17:58, Gary Gregory <garydgreg...@gmail.com> wrote: >> > I think we still have naming problems with the Pair class reflected in >> this >> > Javadoc fragment: >> > >> > * @param <L> the first element type >> > * @param <R> the second element type >> > >> > Either we call them L left and R right, or we call them F first and S >> > second, but mixing both is not good IMO. >> > >> > My preference is for K key and V value. >> >> Key and value implies a relationship between the two parts of the pair >> (the key somehow describes the value), which we cannot do >> (implementing Map.Entry is for convenience, not for any other reason). >> Either first/second or left/right are valid choices. At OpenGamma we >> use first/second but are able to change to left/right if this class is >> released. >> > > I think I like first and second better because we are in a package called > tuple after all. > > When I see left and right, I think of assignments. Why not top and bottom > too then? Just kidding. >
Dee and Dum, ad nauseum... left/right sit nicely with me as I don't place any real priority of one element over the other, which I think numeric names denote. I think I like them for their monosyllabicity as well. That said, http://en.wikipedia.org/wiki/Tuple defines a tuple's elements as being ordered, thus invalidating half of my argument. Are there any equivalents to first/second that are nice and short? Matt > >> >> > I still do not like Pair as a name because a pair is: two identical, >> > similar, or corresponding things that are matched for use together: a >> pair >> > of gloves; a pair of earrings. >> > (http://dictionary.reference.com/browse/pair) >> > >> > We clearly break this common sense definition. >> >> I understand that from an English language POV, but Java devs all over >> know this as a pair. No other name will do I'm afraid. >> > > I'll let it be then. > > Gary > >> >> Stephen >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > > -- > 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