Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78060
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.200 as permitted sender)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
In-Reply-To: <543D7DA5.6050906@gmail.com>
Date: Tue, 14 Oct 2014 20:56:52 +0100
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <6B037BBB-F36F-4F5E-9846-271DC6F55BB5@ajf.me>
References: <8C47FA53-0964-49C0-963C-332A936348A5@ajf.me> <543CE41B.5020308@sugarcrm.com> <C545E75D-109A-4348-9B7E-CDE3A6FD6F57@ajf.me> <543D5C78.9040905@sugarcrm.com> <543D61F3.3000000@lsces.co.uk> <D4F10A0C-6E1A-4BA9-937D-913CB06A7ADB@ajf.me> <543D6B9E.4000205@lsces.co.uk> <30774AB4-3546-4A13-96C6-B511C9F6E12E@ajf.me> <543D7116.2050702@lsces.co.uk> <543D7DA5.6050906@gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Subject: Re: [PHP-DEV] [RFC] Big Integer Support
From: ajf@ajf.me (Andrea Faulds)


On 14 Oct 2014, at 20:46, Rowan Collins <rowan.collins@gmail.com> wrote:

> Just to break this down a bit:
>=20
> 1) The RFC should probably aim to make array keys consistent across =
platforms. This is currently left as an unanswered question in the RFC, =
but it seems natural to include it if the stated aim is to eliminate =
inconsistencies.

It=92s something I do have an answer for, but it=92ll be a separate RFC =
which I need to write a patch for and have pass before this one.

> 2) By using an unlimited type, we open the door to constructing =
"integer"-keyed arrays from 128-bit or larger sources. We also eliminate =
weirdness encountered at the boundaries, such as $foo[PHP_MAX_INT] =3D =
'hello'; $foo[] =3D 'world'; - see http://3v4l.org/69mif

That=92s something which I would handle in the aforementioned =
not-yet-existant RFC.

> 3) On the other hand, an implementation might be possible that allowed =
64-bit integers on 32-bit systems, but nothing more; this would =
potentially be both simpler and more efficient.

More efficient, as in faster? Sure, that=92d be faster. Simpler? Not =
really. The main difficulty in this patch is updating thousands of tests =
and functions. The basics of it (the new type, changes to operators) are =
very easy.

> Implementing both is probably a bad idea, as some core code would then =
need to handle 3 different types of integer (native, emulated 64-bit, =
and GMP), but it could be looked at as an alternative if the current RFC =
is rejected on complexity or licensing grounds.

As all bigint ops are abstracted, you could modify the patch to =
implement 64-bit integers if you wanted. Granted, they=92d be =
unnecessarily allocated their own memory, but it=92d be doable.

--
Andrea Faulds
http://ajf.me/