On Mon, Apr 11, 2011 at 4:25 PM, Matt Benson <gudnabr...@gmail.com> wrote:

> On Mon, Apr 11, 2011 at 1:17 PM, Gary Gregory <garydgreg...@gmail.com>
> wrote:
> > On Mon, Apr 11, 2011 at 2:14 PM, Gary Gregory <garydgreg...@gmail.com
> >wrote:
> >
> >> On Mon, Apr 11, 2011 at 1:52 PM, Stephen Colebourne <
> scolebou...@joda.org>wrote:
> >>
> >>> I fixed the Map.Entry equals/hashCode compliance.
> >>>
> >>> I shortened the toString form to omit the class name, as it is
> >>> superfluous -> (A,B)
> >>>
> >>> Out library uses square brackets, but I can live with round.
> >>>
> >>> I don't believe that requiring every pair to carry around a format
> >>> string is viable. These must be small objects. I could live with a
> >>> toString(format) variation if that would help.
> >>>
> >>> I also believe that getLeftElement()/getRightElement() are too long.
> >>> They should be getLeft()/getRight().
> >>>
> >>
> >> +1, "Element" does not add value (worse would be "Object").
> >>
> >
> > I've done the rename locally and it reads much better in the code. Good
> > suggestion Stephen :) I'll let it site for a little while and commit
> unless
> > tomatoes start flying.
> >
>
> I very much like the field accessors left/right.  getLeft()/getRight()
> sounded a little strange to me, hence the -Element naming (I agree
> -Object would have been worse, hence my choice of element, which I
> also feel conveys the suggestion of "tupleness").  If the majority
> feels getLeft()/getRight() are more palatable, I won't fight it.  I
> suppose bean property conventions make getLeft()/getRight() preferable
> to left()/right(), despite the fact that there seems to be no conflict
> between these ultra-short method names and their public final
> ImmutablePair.* field analogues.
>

The method names should match the ivar names IMO. Doing otherwise is
confusing.

Gary


>
> Matt
>
> > Gary
> >
> >>
> >> I do not like the class name either as I've wrote in another thread: a
> pair
> >> of objects IMO are similar, and I often associate objects together that
> are
> >> not a "pair" in the traditional sense ("a pair of shoes") but that are
> an
> >> association like a key and a value. This is why I use the Smalltalk old
> >> school class name of Association in our version at work.
> >>
> >> Gary
> >>
> >>
> >>> I'd also prefer to make the ImmuatblePair final.
> >>>
> >>> Stephen
> >>>
> >>>
> >>> On 11 April 2011 15:00, Gary Gregory <garydgreg...@gmail.com> wrote:
> >>> > Hi All:
> >>> >
> >>> > I added a test to verify the default Pair toString behavior.
> >>> >
> >>> > For me to replace our custom Pair class at work, I need to customize
> the
> >>> to
> >>> > String behavior.
> >>> >
> >>> > Subclassing ImmutablePair and MutablePair to override toString smells
> >>> nasty.
> >>> >
> >>> > What about adding a formatString ivar which will be used with the
> >>> > String.format API?
> >>> >
> >>> > --
> >>> > 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
> >>>
> >>>
> >>
> >>
> >> --
> >> Thank you,
> >> Gary
> >>
> >> http://garygregory.wordpress.com/
> >> http://garygregory.com/
> >> http://people.apache.org/~ggregory/
> >> http://twitter.com/GaryGregory
> >>
> >
> >
> >
> > --
> > 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
>
>


-- 
Thank you,
Gary

http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory

Reply via email to