commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <gil...@harfang.homelinux.org>
Subject [Numbers] Make "Complex" a "final" class? (Was: [...] API of "Complex")
Date Fri, 02 Feb 2018 12:45:29 GMT
On Thu, 1 Feb 2018 08:30:00 -0700, Gary Gregory wrote:
> 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
> private.

Any caveat on doing that?  Is this a final (!) decision or can one
change one's mind in a later release?
What are the benefits?

Thanks,
Gilles

>
> Gary
>
>
> On Thu, Feb 1, 2018 at 7:07 AM, Gilles <gilles@harfang.homelinux.org> 
> 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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message