On Tue, Jan 31, 2017 at 11:27 AM, Gilles <gil...@harfang.homelinux.org> wrote:
> On Sun, 29 Jan 2017 17:02:05 -0500, Raymond DeCampo wrote: > >> On Sun, Jan 29, 2017 at 11:15 AM, Gilles <gil...@harfang.homelinux.org> >> wrote: >> >> On Sun, 29 Jan 2017 10:36:07 -0500, Raymond DeCampo wrote: >>> >>>> >>>> Well the first use-case that comes to my mind is accepting user input >> from >> some kind of GUI and turning it into a Fraction instance. The second >> would >> be extracting Fraction values from some kind of text representation, e.g. >> CSV file, XML, etc. >> > > I'd agree about parsing the output of "toString()" (i.e. a > "Locale"-independent format, similar to what the JDK does for > subclasses of "Number"). > > But to be able to ensure valid input from CSV, XML, etc. would > require out-of-band information that will clutter the API to no > end. > You've misunderstood. You asked for use-cases. Suppose you are consuming an XML file and wish to end up with Fraction instances. You would use your friendly neighbor XML parser to extract the bits of text from the XML. Then you would use FractionFormat to convert the text into Fraction instances. Just like you would use NumberFormat to convert bits of text from the XML to integers. This requires no additional code in the FractionFormat class. > > But I think we are reaching the end of the useful phase of the discussion >> so that said, I don't really have strong feelings on the matter. I would >> leave it in were it up to me but I wouldn't oppose you if you wanted to >> take it out. >> > > I want to take it out because the current code was unhelpful in the > one case where I needed it (to change the precision of the printed > value, which was about the simplest use-case). And I could not fix it > without a lot of work (to undo what the formatting instance was doing) > in order to get the same output as "toString()"! > > You (and Rob) are most welcome to move the code to [Text] if you see > value in that implementation. > > > > Regards, > Gilles > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
