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

Re: Views on changing Math-BigInt OO design

Thread Previous | Thread Next
From:
Peter John Acklam
Date:
July 28, 2015 13:28
Subject:
Re: Views on changing Math-BigInt OO design
Message ID:
CAEvoY418WrfEwcVBAfDRXLmLzf_C1vRE+Tx7SDEED_50GfMp3g@mail.gmail.com
Abigail, thanks for pointing out the implicit loading. I hadn't though of
that, although hopefully I would have discovered it while testing.

Here is my current idea

- introduce Math::BigNum
- let Math::Big(Int|Float|Rat) each be a subclass of Math::BigNum
- for backwards compatibility, let Math::BigFloat load Math::BigInt, and
let Math::BigRat load Math::BigFloat

Peter


2015-07-28 14:31 GMT+02:00 Abigail <abigail@abigail.be>:

> On Tue, Jul 28, 2015 at 02:16:47PM +0200, David Bundgaard wrote:
> > I would consider that Math::BigFloat to load Math::BigInt to be
> unexpected behavior and should not be endorsed.
>
>
> Unexpected behaviour? It's *documented* to work that way:
>
> From the Math::BigFloat documentation:
>
>        Please note that Math::BigFloat does not use the denoted library
>        itself, but it merely passes the lib argument to Math::BigInt. So,
>        instead of the need to do:
>
>                use Math::BigInt lib => 'GMP';
>                use Math::BigFloat;
>
>        you can roll it all into one line:
>
>                use Math::BigFloat lib => 'GMP';
>
>        It is also possible to just require Math::BigFloat:
>
>                require Math::BigFloat;
>
>        This will load the necessary things (like BigInt) when they are
> needed,
>        and automatically.
>
>
> Now, we may all agree that this was unfortunate, and we even may agree
> the possible breakage is worth the change, but we shouldn't dismiss it
> with "well, it's unexpected behaviour and should not be endorsed".
>
>
>
> Abigail
>

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About