[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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 by
parse() .

The toString() method separates the real and imaginary components by
commas. Separating numbers by commas strikes me as dangerous given that the input expressions to be parsed may also contain commas within the numbers.
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:
 1. "ValJO"
 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 <gilles@xxxxxxxxxxxxxxxxxxxxx>


The contract indicates:[1]
There must be a static factory method capable of creating an
instance from the formal string representation. [...]

Currently "toString" and "parse" do not match.


[1] http://blog.joda.org/2014/03/valjos-value-java-objects.html

To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxx