commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Colebourne <>
Subject Re: FormattableUtils
Date Wed, 04 May 2011 11:24:08 GMT

While I can see the benefits of toString(String format), I'm
struggling to understand what formatTo(...) gains Pair.

I've added a test (in svn), and removed the Formattable interface from
Pair (not in svn), and get the same output, so implementing
Formattable appears to be pointless to me.

I am happy to retain FormattableUItils.

(needs to be decided pre release)


On 25 April 2011 21:40, Matt Benson <> wrote:
> On Mon, Apr 25, 2011 at 8:39 AM, Matt Benson <> wrote:
>> 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 <>
>>>>> On Fri, Apr 22, 2011 at 9:58 AM, Matt Benson <>
>>>>>> 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 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 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
>> format.
>>> 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,
>> FormattableUtils.toString().
>>>, 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.
> Having done a tiny bit of testing here, java.util.Formatter does, as
> Henri seems to have predicted, seem quite brittle.  Its handling of
> various types of Numbers seems to depend on the RT type of the object
> being one of several predefined types rather than just using the
> various Number.*Value() methods, which means that yes, our
> Mutable*(Number) types can't be used with numeric formats.  Further,
> only a limited subset of information is available to Formattable
> implementations, so we really can't do much to make our Mutable*
> classes format attractively.
> Matt
>> Matt
>>> Hen
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message