On Wed, Feb 1, 2017 at 4:43 AM, Gilles <gil...@harfang.homelinux.org> wrote:
> On Tue, 31 Jan 2017 20:25:37 -0500, Raymond DeCampo wrote: > >> 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. >> > > Misunderstood? I'm not so sure. What is the package of the > "NumberFormat" class? > > I was referring to your statement that "ensur[ing] valid input from CSV, XML, etc. would require out-of-band information that will clutter the API to no end." There would be no need for the API (no matter which commons component it lives in) to have any knowledge of the containing text format. > "Double.valueOf", for example, does not parse localized representation > of numbers. Providing the equivalent of "NumberFormat" instead of that > method is going to cause problems.[1] > There is no reason it could not be "in addition to", rather than "instead of". > > So, to summarize, I think that > 1. "valueOf(String)" (and similarly "parseFraction(String)") are fine > to implement in the [Numbers] component.[2] > 2. localized versions should be implemented in the [Text] component. > > And similarly for "Complex" (although in that case, we may end up to > only accept the Cartesian representation). > > Regards, > Gilles > > [1] On systems where the default locale is not "US". > [2] Using private methods or package-scoped classes. > > > >>> 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 > >
