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 <gil...@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.
>
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.
> [1] So this issue:
> https://issues.apache.org/jira/browse/NUMBERS-75
> should probably be resolved as "Invalid".
>
Done. 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, and
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 a new
one?
Eric
