> On 3 Feb 2015, at 21:49, Lester Caine <les...@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’.
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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
