OSDir

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

Re: [Numbers] Re: [...] NUMBERS-68: parse() [...]


Hi.

On Wed, 25 Apr 2018 09:55:13 +0200, Eric Barnhill wrote:
Just to clarify, so the spec for parse() will handle decimal points in
numbers but not commas.

"toString" creates a fixed representation, not Locale-dependent;
"parse" being the inverse function, a decimal comma must be treated
as an error.

For localized representations, there is
  https://docs.oracle.com/javase/7/docs/api/java/text/NumberFormat.html
[See the JDK package name...]

Fine by me.

Thanks.

Gilles

Eric

On Tue, Apr 24, 2018 at 8:53 PM, Gilles <gilles@xxxxxxxxxxxxxxxxxxxxx>
wrote:

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
pseudo-code:

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

Regards,
Gilles



Best,
Gilles

Eric



On Tue, Apr 24, 2018 at 3:38 PM, Gilles <gilles@xxxxxxxxxxxxxxxxxxxxx>
wrote:

Hi.

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.

Regards,
Gilles

[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