Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78042
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.208 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: <543D5C78.9040905@sugarcrm.com>
Date: Tue, 14 Oct 2014 19:01:59 +0100
Cc: PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <3FB11875-5FEC-4CC1-BA13-D910F588D252@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>
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 18:25, Stas Malyshev <smalyshev@sugarcrm.com> wrote:

> Hi!
>=20
>> 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 type isn't hard in itself. The problem is updating
>> everything which handles numbers and their associated tests. This
>=20
> Exactly. Since objects are convertable to numbers (and to anything, in
> fact) we get double profit here - we make objects work better and we
> achieve big integer support. And we don't need to handle new type =
where
> we don't need numbers

Handling a new type in cases where we don=92t need numbers isn=92t =
really a problem.

>=20
>> doesn't make my job any easier. It also wouldn't cover a few places
>> that a new type can, like constants. Another problem is this means
>=20
> I'm not sure I see much case for bigint constants. Would be pretty =
hard
> for me to come up with a case where you need such a constant, and if =
you
> do, you could just have a string constant and convert it to GMP in =
runtime.

Still, it=92s inconvenient. More for developers to worry about.

>=20
>> that bigints are a separate thing from ints, meaning users have to
>> worry about a new type which sometimes behaves differently. This
>> isn't good. Under this RFC's proposal, however, bigints are a mere
>> implementation detail. So far as the user cares, there are just
>> ints.
>=20
> No, they are not implementation detail - they are whole new type, =
which
> means every extension and every piece of PHP code aware of types now
> needs to know about it and needs special code to handle it.

No, only extensions. It is *completely* transparent to userland. That=92s =
the whole point.

> I.e. you
> pass it to mysql - mysql needs to handle this type. You pass it to =
SOAP
> - SOAP needs to handle this type. Etc. But if it's an object, they
> already deal with objects, one way or another.

Yes, but they don=92t handle large integer objects already. So you pass =
it a GMP object, it converts to a string, then that overflows and you =
end up with a float when it converts it to a number. Which isn=92t what =
you wanted. Or, it handles it as a string, which is also not ideal, as =
while a string and an int may be the same thing to some extensions, they =
are not to others.

>=20
>> developers have to check whether or not bigints are enabled and have
>> two different code paths. That's much worse than the status quo.
>=20
> I don't see why you'd have two code paths. If you need bigints and =
they
> are not there, then you just fail, like with any extension your code
> needs and is not installed.

It=92s not about =93extensions your code needs=94. If you need ext/gmp, =
you can already require it. This RFC is about removing cross-platform =
integer handling differences.

> All the code existing now doesn't need bigints, and even in the future
> most code won't need it. But for some code it would just work like
> before, only with unlimited range now.

No, but existing code does have to handle float overflow. If you allow =
that to optionally be int overflow, you now need to worry about handling =
both.

--
Andrea Faulds
http://ajf.me/