On Mon, Apr 11, 2011 at 12:19 PM, Adrian Crum < adrian.c...@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<gudnabr...@gmail.com> >> wrote: >> >> On Mon, Apr 11, 2011 at 9:00 AM, 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? >>>> >>>> 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-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >>> >> > --------------------------------------------------------------------- > 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
