commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@gmail.com>
Subject Re: FormattableUtils
Date Mon, 25 Apr 2011 20:40:56 GMT
On Mon, Apr 25, 2011 at 8:39 AM, Matt Benson <gudnabrsam@gmail.com> wrote:
> On Mon, Apr 25, 2011 at 2:17 AM, Henri Yandell <flamefew@gmail.com> wrote:
>> On Fri, Apr 22, 2011 at 11:32 PM, Henri Yandell <flamefew@gmail.com> wrote:
>>> On Fri, Apr 22, 2011 at 8:58 AM, Gary Gregory <garydgregory@gmail.com>
wrote:
>>>> On Fri, Apr 22, 2011 at 9:58 AM, Matt Benson <gudnabrsam@gmail.com>
wrote:
>>>>
>>>>> On Fri, Apr 22, 2011 at 8:56 AM, Gary Gregory <garydgregory@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 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: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>

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


Mime
View raw message