develooper Front page | perl.perl5.porters | Postings from July 2015

Re: Views on changing Math-BigInt OO design

Thread Previous | Thread Next
James E Keenan
July 28, 2015 11:00
Re: Views on changing Math-BigInt OO design
Message ID:
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 Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About