Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:77970
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.216 as permitted sender)
References: <8C47FA53-0964-49C0-963C-332A936348A5@ajf.me> <543CE41B.5020308@sugarcrm.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <543CE41B.5020308@sugarcrm.com>
Content-Type: text/plain;
	charset=windows-1251
Content-Transfer-Encoding: quoted-printable
Message-ID: <C545E75D-109A-4348-9B7E-CDE3A6FD6F57@ajf.me>
Cc: PHP Internals <internals@lists.php.net>
Date: Tue, 14 Oct 2014 13:18:01 +0100
To: Stas Malyshev <smalyshev@sugarcrm.com>
Subject: Re: [PHP-DEV] [RFC] Big Integer Support
From: ajf@ajf.me (Andrea Faulds)


> On 14 Oct 2014, at 09:51, Stas Malyshev <smalyshev@sugarcrm.com> wrote:
>=20
> Hi!
>=20
>=20
>> Since I don=92t want this to languish as a =91Draft=92 forever, despite t=
he
>> patch being incomplete, I am finally putting the Big Integer Support
>> RFC =93Under Discussion=94.
>>=20
>> The RFC can be found here: https://wiki.php.net/rfc/bigint
>=20
> This introduces new type, IS_BIGINT. However, given that GMP now
> supports arithmetical operations, I wonder if it won't be easier to do
> it in slightly different way, specifically create a hook that is going
> to be called when an operation is about to cause over/underflow and let
> GMP hook there and produce a GMP number (I'm not sure about the exact
> details how to actually do it, so it's just an idea now, but if it makes
> sense we can try to work out technical details).
>=20
> Of course, this would require some rough edges to be polished, such as
> what happens if you try to use it as int, or convert, etc. but this is
> already present with IS_BIGINT too, and additionally we already have
> conversion handlers for objects, which aren't consistently used in all
> cases but can be made so. The benefit is we're not creating anything
> completely new, we just improving how objects work.
>=20
> This would also allow anybody who doesn't like GMP big integers easily
> implement their own module to replace them.
>=20
> Moreover, this also allows to make the support for bigints optional -
> i.e., if you don't need bigints, you don't have to carry GMP and thus do
> not have to be bound by its license.
>=20
> What do you think?

I'm not sure what this would solve. Sure, you could just use objects instead=
 of a new type, but both present exactly the same challenges. Adding a new t=
ype isn't hard in itself. The problem is updating everything which handles n=
umbers and their associated tests. This doesn't make my job any easier. It a=
lso wouldn't cover a few places that a new type can, like constants. Another=
 problem is this means that bigints are a separate thing from ints, meaning u=
sers have to worry about a new type which sometimes behaves differently. Thi=
s isn't good. Under this RFC's proposal, however, bigints are a mere impleme=
ntation detail. So far as the user cares, there are just ints.

Making it optional destroys most of the benefits of the RFC. Instead of redu=
cing platform differences, it adds a massive new one. Now developers have to=
 check whether or not bigints are enabled and have two different code paths.=
 That's much worse than the status quo.

--
Andrea Faulds
http://ajf.me/