Re: [numbers] propose making BigFraction an extension of Fraction
On Thu, 13 Dec 2018 11:20:12 -0800, Eric Barnhill wrote:
Right now BigFraction and Fraction are separate parallel classes.
I propose altering this so that BigFraction extends Fraction,
methods, but also keeps its own unique methods.
I think it would be an improvement to the API to have both classes
the same interface (and indeed an interface-based solution would be
possible, but strikes me as overkill, since I don't see any
classes beyond Fraction and BigFraction). BigFraction would in
have its current methods to convert BigIntegers to ints and longs.
Among the elegancies afforded by this change, if a Fraction operation
causes overflow as previously discussed, a BigFraction could be
and should be able to handle all further calls to Fraction unaltered.
might not always be desired behavior, so Fraction may need to contain
setting to either throw and exception, or convert to BigFraction in
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)?
So I propose writing a ticket for this change. As sub-points on the
the BigFraction class could be conformed to Fraction class in terms
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.
I don't think that we should rule out a "Fraction" interface.
A "Fraction64" class would be an explicit "long"-based ValJO
(with operations that are fast, but throw in case of overflow).
"BigFraction" would be the fail-safe implementation. If it
allows for faster operation in some cases, it could hold
a "Fraction64" instance field (i.e. what you propose would
be achieved through composition rather than inheritance).
Does this make sense?
 So this issue:
should probably be resolved as "Invalid".
To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxx