Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81745
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.41 as permitted sender)
User-Agent: K-9 Mail for Android
In-Reply-To: <54D14268.3050500@lsces.co.uk>
References: <8C47FA53-0964-49C0-963C-332A936348A5@ajf.me> <BCFDECB6-8FBC-4EA1-A081-21BDCC79C1C2@ajf.me> <B9B67D82-CB4E-4CA6-AFAB-25A22EC386B4@ajf.me> <54D00C40.8060907@lsces.co.uk> <54C5DC93-9600-4EE2-BF06-7BF10FC6AD5C@ajf.me> <54D08D50.5050407@lsces.co.uk> <1C2ED70C-72A0-4513-A134-5DAE4CCA5B3D@ajf.me> <54D0DFE5.9030602@lsces.co.uk> <06F175EB-D44A-445F-8015-8421C7C12F39@ajf.me> <54D14268.3050500@lsces.co.uk>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain;
 charset=UTF-8
Date: Tue, 03 Feb 2015 22:39:44 +0000
To: Lester Caine <lester@lsces.co.uk>,internals@lists.php.net
Message-ID: <85032A50-7E7F-40FB-8FEC-D4D185004ACC@gmail.com>
Subject: Re: [PHP-DEV] [RFC] Big Integer Support
From: rowan.collins@gmail.com (Rowan Collins)

On 3 February 2015 21:49:28 GMT, Lester Caine <lester@lsces.co.uk> wrote:
>On 03/02/15 16:44, Andrea Faulds wrote:
>> Sure, but I don’t think we shouldn’t cripple the language merely for
>the sake of really low-end embedded devices. Also, I’m not convinced
>that the overhead, at least in terms of file size, is really that big
>of an issue.
>
>'I don’t think we should cripple' ?
>
>There are two views on the handling of integers. Obviously it would be
>nice if there was no limit to the size of a number and there are
>situations where that is indeed useful. However there are equally
>situations where both the natural 32bit and 64bit limits of the target
>hardware and software needs to be observed and these require a
>different
>method of handling things like 'overflow'. Simply automatically
>upgrading an integer value to a more complex object depending on what
>hardware one is running on adds the overhead of having to create code
>to
>disable things depending on some hardware flag.
>
>With the bulk of SQL persistent data having to manage both 32 and 64bit
>integer limits and the matching float/numeric limits, a system of
>working which mirrors that would naturally seem to be the sensible
>default. If those limitations have been avoided by the use of
>additional
>libraries, then a matching additional library in PHP also comes into
>play.
>
>Currently we have a problem with the size of integers, but simply
>ignoring that there are limits is not the may to fix that problem.

I don't think a high-level language should expose the details of integer representation of the server you install it on any more than it exposes memory management. A user might need to know limitations of the implementation, but they shouldn't be relying on details of it.

Nor should you be relying on your DB server having the same limits as your PHP server, so you'd need to check for 32-bit overflow anyway to install on a 64-bit system.

Making the PHP side predictably support arbitrary precision would seem to remove special cases from userland, not add them. It shunts them into C code, which does all sorts of icky low-level stuff we'd like to ignore already.

-- 
Rowan Collins
[IMSoP]