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