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