commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <>
Subject Re: [Numbers] API of "Complex"
Date Thu, 01 Feb 2018 15:30:00 GMT
Hi All:

I like the "of" prefix but I think it might be odd to force the convention
for ALL factories. It might be an English language thing for me.

For example, (picking a made up example) this reads really well to me:
Pair.of(foo, bar) because that what you'd use in spoken English.

OTOH, this does not read well to me: Fraction.of(num, denum); this would be
better: Fraction.from(num, denum)

All of this to say that we should make sure that the factory method "reads
well" for that class. I know it might feel subjective.

I like the idea of a private ctor but it does not have to be unique in my
mind. Sure, it's nice if there is one.

I also like the idea of the ctor being private because we can open it up
later to protected if we want to allow for subclassing.

I would also consider making classes final, especially if the ctor is


On Thu, Feb 1, 2018 at 7:07 AM, Gilles <> wrote:

> On Thu, 01 Feb 2018 13:59:13 +0100, Gilles wrote:
>> Hi.
>> IMHO, there are too many accessor and factory methods.
>> We should strive for a lean and consistent API.
>> For the factory methods, I suggest the "of" convention:
>>  public static Complex ofCartesian(double re, double im)
>>  public static Complex ofPolar(double abs, double arg)
>> And, as syntactic sugar:
>>  public static Complex ofCis(double arg)
> Those are useful too:
>    public ofReal(double re)
>    public ofImaginary(double im)
>> For the accessors:
>>  public double re() { return real }
>>  public double im() { return imaginary }
>> I'd have
>>   public double arg()
>>   public double abs()
>> in order to compute the polar coordinates.
>> I'm -0 to have others as syntactic sugar since they are
>> misleading (a.o. when "implying" the read of a field when
>> a computation is performed).
>> WDYT?
> In addition to the above, I propose
> * to have a single, "private", constructor:
>     private Complex(double re, double im)
> * to remove the "protected" method "createComplex" (
>   unless there is a case for inheritance).
> Regards,
> Gilles
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message