Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82723
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <6FD9B9A4-E831-4D4F-AD66-BD04D8C37991@ajf.me>
References: <6FD9B9A4-E831-4D4F-AD66-BD04D8C37991@ajf.me>
Date: Sun, 15 Feb 2015 13:07:58 +0000
Message-ID: <CAPwsocEiBZ4T+cBE_-FOfURxDwGK10ORZwjMSYbtDG9WgxVT_w@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [VOTE] Big Integer Support
From: leight@gmail.com (Leigh)

On 15 February 2015 at 02:46, Andrea Faulds <ajf@ajf.me> wrote:
> Hi everyone,
>
> I should=E2=80=99ve done this a long time ago, but I=E2=80=99m going to h=
old a vote on this RFC. The implementation isn=E2=80=99t finished, but the =
remaining work isn=E2=80=99t impossible to surmount (though help would cert=
ainly be appreciated). RFCs can be put to vote without implementations (or =
so says https://wiki.php.net/rfc/howto), so the fact the implementation is =
unfinished isn=E2=80=99t necessarily a blocker.
>
> Putting it to a vote, finally, means I can stimulate further discussion (=
let=E2=80=99s face it, most discussion on a given RFC happens during voting=
), and importantly, see how much support the RFC has in order motivate myse=
lf to finish the implementation.
>
> I think this would be a useful feature for PHP. It brings PHP into line w=
ith other modern dynamic languages in having integers of arbitrary size. It=
 makes integer behaviour both more intuitive and more consistent across pla=
tforms. It (finally) adds a means for handling of 64-bit (and larger) integ=
ers in 32-bit environments. I think allowing integers to grow as needed and=
 not having to worry about platform-specific details is very =E2=80=9CPHP=
=E2=80=9D, as well.
>
> So, anyway, here=E2=80=99s the RFC, including the voting widget:
>
> https://wiki.php.net/rfc/bigint
>
> Voting starts today (2015-02-15) and ends in 10 days (2015-02-25).
>
> If you have any queries, please ask.
>
> Thanks!
>

I think this adds a ton of unnecessary complexity and isn't worth the
breaks or performance degradations that come with it.

We already have big integer support in the form of the GMP extension,
and it is very clear when you are working with arbitrary length
integers. But instead this patch adds GMP as a dependency and hides it
away internally (or for a bigger performance hit, LibTomMath).

Extensions "that deal with numbers" are all going to need updating. So
probably every extension?

You talk about eventually deprecating ext/gmp and moving it to PECL.
Definitely not acceptable.

Sorry, the fixed size integer data type is far too baked-in and
useful. I don't see any gain from this patch except hidden performance
penalties, breaks, and extra work for everyone in maintaining it and
other extensions. I'd rather big int usage was kept verbose and
conscious.

-1