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(). 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
