commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <>
Subject Re: [Numbers] Parsing and formatting classes
Date Wed, 01 Feb 2017 09:43:04 GMT
On Tue, 31 Jan 2017 20:25:37 -0500, Raymond DeCampo wrote:
> On Tue, Jan 31, 2017 at 11:27 AM, Gilles 
> <>
> wrote:
>> On Sun, 29 Jan 2017 17:02:05 -0500, Raymond DeCampo wrote:
>>> On Sun, Jan 29, 2017 at 11:15 AM, Gilles 
>>> <>
>>> 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?

"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]

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).


[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:
For additional commands, e-mail:

View raw message