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.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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
