Just to clarify, so the spec for parse() will handle decimal points in
numbers but not commas.
Fine by me.
Eric
On Tue, Apr 24, 2018 at 8:53 PM, Gilles <gil...@harfang.homelinux.org>
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 <gil...@harfang.homelinux.org>
>>> 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-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
