Shouldn't the FormattableUtils SIMPLEST_FORMAT be "%s"? Gary
On Mon, Apr 25, 2011 at 9:39 AM, Matt Benson <[email protected]> wrote: > On Mon, Apr 25, 2011 at 2:17 AM, Henri Yandell <[email protected]> wrote: > > On Fri, Apr 22, 2011 at 11:32 PM, Henri Yandell <[email protected]> > wrote: > >> On Fri, Apr 22, 2011 at 8:58 AM, Gary Gregory <[email protected]> > wrote: > >>> On Fri, Apr 22, 2011 at 9:58 AM, Matt Benson <[email protected]> > wrote: > >>> > >>>> On Fri, Apr 22, 2011 at 8:56 AM, Gary Gregory <[email protected] > > > >>>> 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. > > Matt > > > > > Hen > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Thank you, Gary http://garygregory.wordpress.com/ http://garygregory.com/ http://people.apache.org/~ggregory/ http://twitter.com/GaryGregory
