On 05/02/15 16:24, Rowan Collins wrote: >> The simple answer here is that there is not a 'single' definition of >> integer ... > > True. But the definition of "integer" in PHP is, and has been for many > years, "as big as this build can handle". With Andrea's patch, all > systems can handle really really big integers, which seems like a big > win to me.
Have no argument with the statement - but implementing it creates a need for a BC compatible constrained integer. So we have the situation where the option for an unconstrained integer is already available via the extension, so does it make sense to make it the default since it also requires a lot more code to handle the constrained cases. The problems between 32 and 64 bit builds still needs to be handled where other 'integer' values don't have the luxury unlimited counts, but simply ignoring the limits does not make sense. The discussion is a little like debate as to if mbstring should be part of core or remain an add-on. Who gets the biggest gain or loss from each option? Just as in my book there is no single 'integer' constraint, there is no single 'string' constraint. A string length/position can't be stored in an unconstrained integer, so we need a constrained holder for that and it's limits depend on the type of string being stored and the platform. -- 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
