> On 3 Feb 2015, at 21:49, Lester Caine <[email protected]> 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’.
Maybe. But PHP has never cared about those things. We promote to float when integers would
“overflow” in another language.
> 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.
Not really. We already do promotion for integers to float, and it’s a very simple operation to
check for overflow, natively supported by many compilers, and we also have a pure C fallback. All
that bigints do is that instead of promoting to float, we promote to bigints. There’s no new
overhead, these checks already existed, and have done for well over a decade.
The only complexity bigints add are the addition of the new IS_BIGINT type (which goes in your
operator type matrices etc.), and requiring some bigint library.
> 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.
Why should it match SQL? Why should we have the complexity of two different sizes of integer? Why
not just have a single, unified arbitrary-precision integer type, like the RFC proposes.
> 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.
This RFC doesn’t ignore that there are limits. Arbitrary-precision integers are, naturally,
bounded by available RAM (including the request memory limit).
--
Andrea Faulds
http://ajf.me/