commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <gil...@harfang.homelinux.org>
Subject Re: [numbers] propose making BigFraction an extension of Fraction
Date Thu, 27 Dec 2018 22:12:25 GMT
Hi Eric.

On Thu, 27 Dec 2018 11:53:39 -0800, Eric Barnhill wrote:
> Thanks for this response and it took me some time to think your 
> various
> points through.
>
> On Thu, Dec 13, 2018 at 4:59 PM Gilles <gilles@harfang.homelinux.org> 
> wrote:
>
>>
>> On Thu, 13 Dec 2018 11:20:12 -0800, Eric Barnhill wrote:
>>
>> > Among the elegancies afforded by this change, if a Fraction 
>> operation
>> > causes overflow as previously discussed, a BigFraction could be
>> > returned
>> > and should be able to handle all further calls to Fraction 
>> unaltered.
>> > (This
>> > might not always be desired behavior, so Fraction may need to 
>> contain
>> > a
>> > setting to either throw and exception, or convert to BigFraction 
>> in
>> > case of
>> > overflow.)
>>
>> Doesn't this setting achieve at runtime what the application
>> developer should decide at compile time (by instantiating the
>> class that has the desired behaviour)?
>>
>
> Yes. Perhaps I have been spending too much time writing Python 
> lately.

:-)

>>
>> >
>> > So I propose writing a ticket for this change. As sub-points on 
>> the
>> > ticket
>> > the BigFraction class could be conformed to Fraction class in 
>> terms
>> > of
>> > reduction of constants and producing a VALJO.
>>
>> Inheritance and ValJO turn out being contradictory (see thread
>> with subject "Inheritance and ValJO ?").
>> And (IIUC) the workaround/alternative hinted at by Stephen
>> in that same thread might not be directly applicable because,
>> here, the instance fields are different in "Fraction" and
>> "BigFraction" ("long" vs "BigInteger").
>>
>> I've just noticed that "BigInteger" is not final; hence
>> "BigFraction" cannot be a ValJO either.[1]
>>
>
> It sounds like this is sufficient to disqualify this proposal.
>
>
> I don't think that we should rule out a "Fraction" interface.

Maybe not.
How to call the implementations?  "BigFraction" and ...
"SmallFraction"?

>
> Since BigFraction and Fraction have the use cases covered for now
> (improved, I would argue, by only the former requiring Big* classes) 
> I
> propose wrapping up this work and leaving this until after a release.

Fine.

>> [1] So this issue:
>>        https://issues.apache.org/jira/browse/NUMBERS-75
>>      should probably be resolved as "Invalid".
>>
>
> Done.

Thanks.

> But, there were some "peripheral" improvements that came out of
> making Fraction a ValJO that should still be applied to BigFraction, 
> for
> example conforming both classes to use the same factory methods,

+1

> and
> reducing the absurd number of BigFraction constants.

+1

> Shall I reopen and
> rename the ticket to focus on these changes, or is it better to start 
> a new
> one?

I'd go for new one.

Best regards,
Gilles

>
> Eric


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message