Hello.
> >
> >Gilles commented on MATH-614:
> >-----------------------------
> >
> >Above code added in revision 1145932.
> >Is there a case against that implementation?
>
> I'm not sure I understand well.
> Shouldn't the toString method be based on some default configuration
> of ComplexFormat and most importantly be such that it can be parsed
> back using ComplexFormat ?
In principle, no. I've read somewhere that, as a rule, users should *not* be
encouraged to consider the output of "toString" as a standard representation
of the instance. It's purpose is to provide easy printing/logging but it's
not a substitute for serialization.
> I fear that the current implementation can be written but not read.
> ComplexFormat takes care to be able to do both.
At first, I also thought that it should use the default "ComplexFormat". But
even it could, there is a disadvantage, if we want the output of "toString"
to be a faithful representation of the two real numbers that compose the
complex number: E.g.
---CUT---
double a = 1.12345678910111213;
double b = 1.98765432123456778;
Complex c = new Complex(a, b);
log.debug("a={}", a);
log.debug("b={}", b);
log.debug("c={}", c);
---CUT---
The 3 log statements will indirectly use "toString" but in the third, the
"a" and "b" components will not be output in the same way as in the 2
preceding statements because of the use of "ComplexFormat". This could be
fairly confusing...
Regards,
Gilles
