Am 25.04.2011 09:17, schrieb Henri Yandell:
On Fri, Apr 22, 2011 at 11:32 PM, Henri Yandell<flame...@gmail.com>  wrote:
On Fri, Apr 22, 2011 at 8:58 AM, Gary Gregory<garydgreg...@gmail.com>  wrote:
On Fri, Apr 22, 2011 at 9:58 AM, Matt Benson<gudnabr...@gmail.com>  wrote:

On Fri, Apr 22, 2011 at 8:56 AM, Gary Gregory<garydgreg...@gmail.com>
wrote:
Hi All:

Now that we have the shiny and new FormattableUtils class, what are the
other opportunities in [lang] to eat our own dog food?


What did you have in mind?


I am just wondering what other [lang] classes should be Formattable.
StopWatch for example?

Having hijacked the thread; possible Formattables that jump out:

Fraction
Range
StopWatch
The Mutables (or maybe Formatter knows special things about Number already)
BitField

So I think the full potential list is the above plus StrBuilder,
CharSet and JavaVersion.

I'm not sure if it makes sense for each; but those are our current
custom business objects.

I'm scratching my head over Pair a bit though. What benefit did we add
by implementing Formattable? My off-hand comment was hoping we would
replace Gary's need to have his own subclass just to change the
format, but he still needs that.

I'm also not sure of the benefit of FormattableUtils.append. We pass a
CharSequence in and do much what the JDK would do on the toString?

It almost feels that we need to add our own Formattable interface, but
instead of formatTo we would have toString(String format). That's a
weak API though. Users can't dictate whether the left or right comes
first for the Pair example, they're stuck with left then right. The
'better' solution is to have a PairFormat class that has its own
custom pattern language (%L and %R etc).

What am I missing?

Currently I feel that we can dump FormattableUtils, simplify the
toString on Pair and tell Gary to suck it up, and then go do a bunch
of testing to see if the Mutables will work with String.format's
numerical flags (I'm suspecting it doesn't, making these irritating to
use and in need of some javadoc to warn the user).

Hen

Could we introduce a generic pattern language based on the properties of the objects to be formatted? For the Pair class an example pattern could look like "({left}, {right})".

The variables could be resolved by reflection calls. FormatUtils could do this and implement the padding stuff in a generic way.

This would not directly solve the original problem - having a customizable toString() method. But it would at least provide a convenient way to transform objects to strings.

Oliver

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

Reply via email to