On Wed, May 4, 2011 at 6:24 AM, Stephen Colebourne <scolebou...@joda.org> wrote:
> So....
>
> 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.
>
:) If you follow the original trail of discussion, it seems to have
been a misunderstanding on my part. We were discussing the propriety
vs. brittleness, etc., of the String toString(String format) method on
Pair and Hen mentioned Formattable. I didn't see how that could be
used to accomplish the same thing, but in my respect for Hen I simply
assumed I wasn't understanding him and reinterpreted the statement
until I came to an interpretation that I could comprehend: that we
use the Formattable part of the formatter APIs, and, necessarily,
subclassing, to specialize the output of a Pair. After the fact Hen
stated this wasn't what he meant. I'm still not sure exactly what he
did mean, but I didn't press the issue. Gary felt strongly about not
needing to subclass (understandably) and restored toString(String).
At some point Hen mentioned the idea of a PairFormat class. I don't
think this is a bad idea, but the parsing capabilities of such a beast
would be minimal to nonexistent, and it still doesn't seem that it
would be configurable in a simple way without doing the equivalent of
String.format("", left, right). At this point I am still not sure
what is the right mechanism for providing custom string
representations of Pair in the simplest and most elegant possible way.
Have any ideas?
> I am happy to retain FormattableUItils.
Yes, I am satisfied that it does its job regardless of the Pair debate.
Matt
>
> (needs to be decided pre release)
>
> Stephen
>
>
>
>
> On 25 April 2011 21:40, Matt Benson <gudnabr...@gmail.com> wrote:
>> On Mon, Apr 25, 2011 at 8:39 AM, Matt Benson <gudnabr...@gmail.com> wrote:
>>> On Mon, Apr 25, 2011 at 2:17 AM, Henri Yandell <flame...@gmail.com> wrote:
>>>> 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 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-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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
