Le 13/07/2011 14:33, Gilles Sadowski a écrit :
Hello.
Hi,
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...
OK, it's fine with me.
Thanks for the explanation.
best regards,
Luc
Regards,
Gilles
