Re: [numbers] propose making BigFraction an extension of Fraction
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
On Thu, Dec 13, 2018 at 4:59 PM Gilles <gilles@xxxxxxxxxxxxxxxxxxxxx>
On Thu, 13 Dec 2018 11:20:12 -0800, Eric Barnhill wrote:
> Among the elegancies afforded by this change, if a Fraction
> causes overflow as previously discussed, a BigFraction could be
> and should be able to handle all further calls to Fraction
> might not always be desired behavior, so Fraction may need to
> setting to either throw and exception, or convert to BigFraction
> case of
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
> So I propose writing a ticket for this change. As sub-points on
> the BigFraction class could be conformed to Fraction class in
> 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.
It sounds like this is sufficient to disqualify this proposal.
I don't think that we should rule out a "Fraction" interface.
How to call the implementations? "BigFraction" and ...
Since BigFraction and Fraction have the use cases covered for now
(improved, I would argue, by only the former requiring Big* classes)
propose wrapping up this work and leaving this until after a release.
 So this issue:
should probably be resolved as "Invalid".
But, there were some "peripheral" improvements that came out of
making Fraction a ValJO that should still be applied to BigFraction,
example conforming both classes to use the same factory methods,
reducing the absurd number of BigFraction constants.
Shall I reopen and
rename the ticket to focus on these changes, or is it better to start
I'd go for new one.
To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxx