commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <>
Subject Re: FormattableUtils
Date Mon, 25 Apr 2011 13:39:05 GMT
On Mon, Apr 25, 2011 at 2:17 AM, Henri Yandell <> wrote:
> On Fri, Apr 22, 2011 at 11:32 PM, Henri Yandell <> wrote:
>> On Fri, Apr 22, 2011 at 8:58 AM, Gary Gregory <> wrote:
>>> On Fri, Apr 22, 2011 at 9:58 AM, Matt Benson <> wrote:
>>>> On Fri, Apr 22, 2011 at 8:56 AM, Gary Gregory <>
>>>> wrote:
>>>> > Hi All:
>>>> >
>>>> > Now that we have the shiny and new FormattableUtils class, what are
>>>> > 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 don't know of any way to use the Formattable interface to accomplish
what you suggest, hence my initial confused comment.  Having gone back
to reread the Javadoc examples, I concluded your intent was that if we
were going to provide custom interactivity with the formatter APIs we
should do it in a way conforming to the design of those classes.  The
current example does this, but--you are correct--returns us to the
state of affairs wherein a subclass is needed to customize an object's

> 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?

If you look at the Formattable API and example implementation in the
class javadoc, the takeaway is that every Formattable implementation
must handle width (number of characters to fill), precision (maximum
width of meaningful data), and justification (provided simply as
pad-left or, by exclusion, -right).  It was my feeling that 95% of
implementations would therefore embed redundant code, with the main
potential for divergence (due to their being unspecified by the
interface) being the pad character used, and the form taken by the
"ellipsis" when the meaningful output overflows the specified
precision.  For this reason I extracted FormattableUtils.append to
handle what I saw as the redundant part of implementing Formattable.
This strikes me as a perfect fit for [lang].  Note that the way in
which I am *least* satisfies with this method's implementation is
that, like the example in Formattable's javadoc,
Formatter.format(CharSequence) is called as part of the
implementation.  I would have preferred the implementation to write
directly to the Formatter's Appender; however I could find no
specification as to how to handle any theoretically encountered
IOExceptions, which are somehow swallowed by Formatter.format().  I
therefore opted for consistency by virtue of dropping back into the
formatter APIs as suggested by the designers (I personally think this
is a somewhat flawed design at least in this respect).

> 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).

It does seem as though the old Format APIs might be more appropriate
to custom formatting.  My hesitation there is that most often you're
going to encounter the situation where you're providing a
self-consciously incomplete implementation because what you can
format, you can't necessarily parse.

> What am I missing?
> Currently I feel that we can dump FormattableUtils

I hope I've explained why I feel #append is useful.  Further, if you
agree with the idea that it would be predictable for a Formattable to
use its own basic format as its toString(), providing a quick
shorthand to format a Formattable to a string seems like a harmless
opportunity to eliminate boilerplate; hence,

>, simplify the
> toString on Pair and tell Gary to suck it up,

In this regard, and in light of the "brittle API" you pointed out as
created by toString(String format)
and-here-are-the-parameters-you-have-available, perhaps
String.format(formatString, pair.getLeft(), pair.getRight(), ...) is
the right prescription here.

> 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).

Or just make them work if there are solvable problems.


> Hen
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message