On Wed, 1 Feb 2017 07:36:32 -0500, Raymond DeCampo wrote:
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.
At the very least, the "Locale" of the input must be passed, or
problems
will ensue. "Locale" is "out-of-band" IMHO.
"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".
Agreed. That's what I wrote in the previous message (quoted below)...
And in this case, I'd rather stick to the layout of the JDK, which
emphasizes that the two functionalities are distinct.
You may not agree that [Text] is a better home, but then you have to
make the case why.
Please note that we should strive to make the "spin-offs" of Commons
Math as stable as possible. I certainly would like to avoid any
potentiality of having to release Numbers 2.0 because we copied a 10
years old utility (that was probably never used outside of Commons
Math's error message formatting) without having looked at better
alternatives.
IMO, the game is currently about finding the truly low-level math
utilities, and make them really independent (that is bona-fide
components) so that their development become separate, guided
by internal consistency and not entangled with released scheduled
to fix unrelated stuff.
In the case of a "fraction", the accessors
getNumerator()
getDenominator()
are the only inputs required in order to create a string representation
of the instance.
These accessors are trivial (and thus unlikely to ever need an API
break) while the formatting part is far from trivial, and surely
would benefit from more elaborate functionality likely to also be
part of [Text].
I hope I made my point clear this time. :-}
Gilles
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
