commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adrian Crum <adrian.c...@sandglass-software.com>
Subject Re: [Lang] Pair toString
Date Mon, 11 Apr 2011 16:59:32 GMT
There is no aversion to customizing toString(). You said your choices 
were subclassing, delegating, or convince the Commons community to 
change the Pair class. If the Pair class isn't changed, then you're left 
with the first two options. Personally, I prefer using the "has a" 
pattern over the "is a" pattern - that's why I suggested delegation.

-Adrian

On 4/11/2011 9:30 AM, Gary Gregory wrote:
> On Mon, Apr 11, 2011 at 12:19 PM, Adrian Crum<
> adrian.crum@sandglass-software.com>  wrote:
>
>> Delegating is trivial in Eclipse - it will write the code for you. As for
>> delegating versus "rolling your own" - delegating leverages the code
>> maturity and unit tests of the delegate.
>>
> Roger that. Speaking of Pair and 'code maturity' at this point is a bit
> premature IMO.
>
> Here is what I have in front of me with lang3 as it is today:
> - A simple proprietary pair class with flexible toString. Unit tested.
> - A simple FOSS pair class without flexible toString. Unit tested.
>
> I love to replace our custom gadgets with FOSS code, no need to explain that
> one :)
>
> In this case, this is not a drop in replacement. Choices:
> - Do nothing.
> - Subclass twice and add customizable toStrings.
> - Delegate and add customizable toStrings.
>
> Since the class is so simple (a fancy wrapper) it is hard to justify
> anything but 'do nothing.' ATM.
>
> Am I reading an unspoken aversion to customizing toString behavior?
>
> Thank you,
> Gary
>
>
>> -Adrian
>>
>>
>> On 4/11/2011 9:16 AM, Gary Gregory wrote:
>>
>>> On Mon, Apr 11, 2011 at 10:12 AM, Matt Benson<gudnabrsam@gmail.com>
>>>   wrote:
>>>
>>>   On Mon, Apr 11, 2011 at 9:00 AM, Gary Gregory<garydgregory@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?
>>>>>
>>>>>   If we must do anything like this it would seem that by the laws of
dog
>>>> food we would accept Builder<String>.  That said, I'm finding it
>>>> difficult to see a way to do this that doesn't seem equally offensive
>>>> as the subclassing approach you've rejected.  For a different
>>>> subclassing approach you could implement toString() at a single
>>>> point--a direct Pair subclass--and then reimplement mutable and
>>>> immutable versions if you really needed both.  Or if your toString()
>>>> needs are nonspecific enough, maybe we can just use them--I'm not
>>>> unduly attached to the current format.
>>>>
>>>>   Brrrr. struggling with this one.
>>> The subclassing approach seems messy. Delegating is not much better. Pair
>>> is
>>> simple enough that (gasp) duplicating maybe less smelly, but that is what
>>> I
>>> have now, my own Pair kind of class with the additional feature that
>>> toString is customizable, sometimes I use ": ", "=", or " =>   " as the
>>> separator (no class name, no parens).
>>>
>>> When I think about a Map or List string dump in the current format, it
>>> will
>>> look noisy. This is why allowing a pluggable toString makes sense.
>>>
>>> Again: What about adding a formatString ivar which will be used with the
>>> String.format API? Or something that will let me use Pair as is and plugin
>>> a
>>> formatter? I fear subclassing or delegation might be the required hack for
>>> me :( But why bother then, I'd be better off not using Pair :( for my use
>>> cases that need to be toString'd.
>>>
>>> Thank you,
>>> Gary
>>>
>>>
>>>   Matt
>>>>   --
>>>>> Thank you,
>>>>> Gary
>>>>>
>>>>> http://garygregory.wordpress.com/
>>>>> http://garygregory.com/
>>>>> http://people.apache.org/~ggregory/
>>>>> http://twitter.com/GaryGregory
>>>>>
>>>>>   ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message