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. I am happy to retain FormattableUItils. (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
