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 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
