Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82725
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)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
In-Reply-To: <CABBJUpcpUiXTX4hv=Lj6JMWhxRriV8c+8kD50gUk7Cq-hhqM+A@mail.gmail.com>
Date: Sun, 15 Feb 2015 13:45:49 +0000
Cc: PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <8814DFF5-3B94-4B2D-8A02-49B17AC307F5@ajf.me>
References: <6FD9B9A4-E831-4D4F-AD66-BD04D8C37991@ajf.me> <CABBJUpcpUiXTX4hv=Lj6JMWhxRriV8c+8kD50gUk7Cq-hhqM+A@mail.gmail.com>
To: Xinchen Hui <laruence@php.net>
Subject: Re: [PHP-DEV] [VOTE] Big Integer Support
From: ajf@ajf.me (Andrea Faulds)

Hi,

> On 15 Feb 2015, at 12:39, Xinchen Hui <laruence@php.net> wrote:
>=20
> On Sun, Feb 15, 2015 at 10:46 AM, Andrea Faulds <ajf@ajf.me> wrote:
>> Hi everyone,
>>=20
>> I should=E2=80=99ve done this a long time ago, but I=E2=80=99m going =
to hold 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 certainly 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.
> for such a big change, the implementation self is also important,
> there was some RFC accepted with "not good" implementation, which
> cause lots of troubles for us to maintaining .

This vote isn=E2=80=99t to be thought of as accepting the =
implementation, merely the feature. If the implementation isn=E2=80=99t =
good enough, the feature could actually be dropped for PHP 7, as much as =
I hope that won=E2=80=99t happen.

>>=20
>> 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 myself to finish the implementation.
>>=20
>> I think this would be a useful feature for PHP. It brings PHP into =
line with other modern dynamic languages in having integers of arbitrary =
size. It makes integer behaviour both more intuitive and more consistent =
across platforms. It (finally) adds a means for handling of 64-bit (and =
larger) integers 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.
>>=20
> from your RFC:
> "
> but obviously the implementations of anything dealing with integers
> may need to be changed."
>=20
> this sounds too much compare to the benefits it brings.. (User can use
> bcmath or other similar thing to deal with big int).

It=E2=80=99s not a massive change. All the places in core have already =
been changed. Most extensions taking integers do so via zpp=E2=80=99s =
=E2=80=9Cl=E2=80=9D type (or FAST_ZPP=E2=80=99s Z_PARAM_LONG), which =
handles bigints properly. The main issue is functions accepting zvals =
(=E2=80=9Cz=E2=80=9D or Z_PARAM_ZVAL). In such cases, the change is =
usually two lines of code to add an IS_BIGINT case to a switch.

> and actually, I'd prefer this to be a extension instead of get it into =
core..
>=20
> too much changes for little gains..
>=20
> Thus, I voted -1 on this.

Alright, I can understand your perspective.
--
Andrea Faulds
http://ajf.me/