On Tue, 31 May 2016 11:12:06 +0200, Eric Barnhill wrote:
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.
That will be nice.
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.
I'm not sure how you can draw a line between "getters" and
"derivative".
The prefix "get" is often used to imply that a field is read, but
it contradicts the idea of "encapsulation".
The advantage of full names is that they are self-documenting.
That convention is predominant is CM (i.e. no abbreviations), except
where a prior established convention exists (like for well-known math
functions).
Here we seem to fall in the latter.
So why not
* abs()
* arg()
* re()
* im()
?
Short as can be and close to math notation.
Another possibility may be to keep long names and to add syntactic
sugar such as
-----
public static double im(Complex c) {
return c.getImaginary();
}
-----
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[] .
Shall we consider making the constructors "private" and define
factory methods (like those currently in "ComplexUtils")?
public static Complex createCartesian(double re,
double im) {
return new Complex(re, im);
}
public static Complex createPolar(double r,
double theta) {
return new Complex(r * FastMath.cos(theta),
r * FastMath.sin(theta));
}
And suppress the ambiguous methods "createComplex" and
"valueOf".
Actually I think that only one constructor should stay that
is tied to the underlying representation (and for that reason
it should not be "public").
What do you think?
Gilles
Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
