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 > > -- Thank you, Gary http://garygregory.wordpress.com/ http://garygregory.com/ http://people.apache.org/~ggregory/ http://twitter.com/GaryGregory
