Lester Caine wrote on 05/02/2015 16:49:
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.
I disagree. There is no consistently constrained integer in any recent
version of PHP, since it is build-dependent. The fact that all the
builds you routinely use are 32-bit gives you the illusion that this is
a standard constraint.
It's a bit like the difference between parsing the User-Agent of a
browser, and dynamically testing a particular feature - what is it you
actually need to know? If what you need to know is "is this integer
outside the range of a 32-bit signed int", then "if ( $foo >= pow(2,31)
)" is a more logical test than "if ( is_float($foo) )" anyway.
The only reason this would be a compatibility break is if code is using
the overflow-to-float (which you agree is undesirable) as a proxy
measure of the underlying platform type. If what you need to know is
genuinely "am I running on a 32-bit build of PHP", then what you need is
some functionality for probing that; perhaps PHP_INT_SIZE?
There may be an argument for *introducing* constrained integer types,
but doing so would be nothing to do with backwards compatibility.
Note that I am talking purely about the PHP userland here, not C
extensions. The extension API absolutely should have convenient
functions for range-checking ints of various sizes, be that 64-bit,
32-bit, 16-bit, or whatever; this is true whether or not userland
integers are made arbitrary-precision.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
