Re: [Numbers] Re: [...] NUMBERS-68: parse() [...]
On Tue, 24 Apr 2018 16:29:58 +0200, Gilles wrote:
On Tue, 24 Apr 2018 16:05:32 +0200, Eric Barnhill wrote:
I would prefer to conform toString() to the current formats accepted
The toString() method separates the real and imaginary components by
commas. Separating numbers by commas strikes me as dangerous given
input expressions to be parsed may also contain commas within the
The format "x + yi" strikes me as satisfyingly unambiguous.
If I'm not mistaken, the current "parse" will choke on "x - yi"...
I understand the intent, but I think that there are two issues
on that matter:
2. Convenience/Standard notation
IMHO the former belongs to the "Complex" class, the latter not.
For the former, I'd favour the KISS principle, which in this
case would be to only accept (i.e. read) only what "toString"
would have written.
Note that we talk here only about machine input/output, not
all the variations that one would deem necessary for human
(dangerous! ;-) input.
Flexible (or intended to be) parsing is a can of worm that
is better left for an independent utility defined in another
class; even better in another module that could depend on
another component that would offer advanced interpretation
capabilities (e.g. "Commons Text").
That way we can also create common code for all the "number"
classes, without circular dependencies.
Concretely, for the "ValJO", I suggest the following parsing
Read a '('
Read a "double"
Read a ','
Read a "double"
Read a ')'
If you agree with the above rationale, I have the code ready
(with unit tests).
On Tue, Apr 24, 2018 at 3:38 PM, Gilles
The contract indicates:
There must be a static factory method capable of creating an
instance from the formal string representation. [...]
Currently "toString" and "parse" do not match.
To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxx