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. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
