I propose some minor changes in Complex() methods nomenclature for 4.0 . These relate to the collection of methods abs(), getArgument(), getReal() and getImaginary() .
Personally I switch frequently and freely between Cartesian and polar representations of complex numbers in my code. So to me it would make more sense to conform the terminology of these arguments, which would effectively make Complex unbiased as to which representation you use. Keeping the prefix "get" has sound logic to it as it establishes these methods as accessor type methods as opposed to other Complex methods like sin(), which are more derivative. Some abbreviation is in order to avoid getAbsoluteValue(), so I propose getAbs(), getArg(), getReal(), and getImag() as the four method names. This leaves only the question of a constructor that takes polar representations which I think is already well handled by the present method ComplexUtils.polar2Complex, for either Complex or Complex[] . Eric
