On Wed, Apr 20, 2011 at 3:25 PM, Gary Gregory <[email protected]> wrote:
> On Wed, Apr 20, 2011 at 5:07 PM, Matt Benson <[email protected]> wrote:
>
>> On Wed, Apr 20, 2011 at 3:46 PM, Gary Gregory <[email protected]>
>> wrote:
>> > On Wed, Apr 20, 2011 at 4:36 PM, Jörg Schaible <[email protected]
>> >wrote:
>> >
>> >> Gary Gregory wrote:
>> >>
>> >> > On Wed, Apr 20, 2011 at 1:24 PM, Matt Benson <[email protected]>
>> >> wrote:
>> >> >
>> >> >> On Wed, Apr 20, 2011 at 1:10 AM, Henri Yandell <[email protected]>
>> >> >> wrote:
>> >> >> > Is Pair now good (for a value of consensually agreed good)?
>> >> >>
>> >> >> Good enough, although Stephen noted in ImmutablePair's javadoc that
>> >> >> being non-final, a subclass could add
>> >> >> undesirable/counter-to-expectation behavior.  I can't see any reason
>> >> >> why we shouldn't make this class final, particularly as the option
>> >> >> always exists to lift that restriction should someone later provide a
>> >> >> justification for doing so.  Does anyone object to this?
>> >> >>
>> >> >
>> >> > Please do not make the class final.
>> >> >
>> >> > The first thing I want to do is dump my custom pair class and plug
>> this
>> >> > one in. But, in order to do so, I need to override toString().
>> >> >
>> >> > Which gives me another custom class... so why do I want to do this?
>> Hm...
>> >> > good question. Until I play with it some more, I am not sure which way
>> to
>> >> > go for my use case. Just don't lock me out ;)
>> >>
>> >> Couldn't you use in that case Pair<T,U> directly?
>> >>
>> >
>> > If I use a pair directly, then the call site has to know about the
>> toString
>> > argument, which I want to hide in a subclass. I could have a MyPairUtils
>> > that hides it instead I suppose. Not the prettiest but it avoids
>> subclassing
>> > I suppose.
>> >
>> > Still, don't lock me out from trying :)
>> >
>>
>> I think Sebastian was suggesting you implement:
>>
>> public class GarysImmutablePair<L, R> extends Pair<L, R> {
>>
>>  //construct, implement getLeft()/getRight(), whatever...
>>
>>  public String toString() {
>>    return toString("look at me I'm a pair of (%s:%s) yo");
>>  }
>>
>>
> Right, it makes me question the sanity of porting from my class to this one
> :(
>
> Gary
>
>
>> But I admit it does look like quite a bit of work needed just to
>> override toString().  Also possible could be introducing
>> AbstractImmutablePair into the inheritance chain, but feels like a lot
>> just to get a final class.  I'm fine to leave as-is.

PairFormat class needed rather than relying on toString functionality :)

Could we implement Formattable?

Hen

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to