Front page | perl.perl5.porters |
Postings from July 2015
Re: Views on changing Math-BigInt OO design
Thread Previous
|
Thread Next
From:
James E Keenan
Date:
July 28, 2015 11:00
Subject:
Re: Views on changing Math-BigInt OO design
Message ID:
20150728110020.27229.qmail@lists-nntp.develooper.com
On 07/28/2015 04:39 AM, Peter John Acklam wrote:
> I want to change the OO design of the Math-BigInt distribution, but before
> I do so, I would like your opinion.
>
> Current implementation:
>
> Currently, Math::BigInt is the superclass of Math::BigFloat, which in turn
> is the superclass of Math::BigRat. This OO design doesn't make sense. None
> of Math::BigInt, Math::BigFloat, and Math::BigRat have an internal
> structure which is a superset/subset of any of the others. Methods like
> band(), bor() etc. make sense on Math::BigInt objects, but don't make sense
> on Math::BigFloat objects and Math::BigRat objects, who inherits the
> methods band(), bor() etc.
>
> TELS, who introduced this design, seemed to be aware of the problems, and
> as a sort of workaround let Math::BigFloat->isa("Math::BigInt") return
> false. Ditto for Math::BigRat. This doesn't solve the real problems and
> causes problems (e.g., endless recursion) when creating subclasses.
>
> New implementation:
>
> I want to introduce Math::BigNum as a virtual parent class, and let
> Math::BigInt, Math::BigFloat, and Math::BigRat be subclasses of
> Math::BigNum. Math::BigNum will implement the very few methods that
> Math::BigInt, Math::BigFloat, and Math::BigRat have in common as well as
> some internal utility functions.
>
> Would this be OK?
>
This sounds worth exploring. If I understand you correctly, the end
user's interface would not change.
> Regards,
> Peter John Acklam
> (current maintainer of Math-BigInt, Math-BigRat, and bignum)
>
Thread Previous
|
Thread Next