On Mon, Apr 25, 2011 at 11:22 AM, Oliver Heger <oliver.he...@oliver-heger.de
> wrote:
> 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.
>
That sounds nice... and complicated (and not doable for 3.0?) ATM, the
simplest solution is aPair.toString("...%1$...%2$ ...");
I like the simplicity of the thing. A toString(String format) could be
implemented to all our 'business' objects.
Someone mentioned brittleness. It seems as brittle as the API of any given
class that would implement such a method. We could have a guideline/rule
that only publicly accessible data ends up in the argument as %n. This would
mean that if the API were deleted, it would also be permitted to change the
toString(String). Or, simply that changing the toString(String) is the same
as our other contracts, it can only be broken in a major release. It's
another that can be broken, yes, but that's just like any API.
Gary
> Oliver
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
--
Thank you,
Gary
http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory
