Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81954
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.178 as permitted sender)
Message-ID: <54D3B13E.4000205@gmail.com>
Date: Thu, 05 Feb 2015 18:06:54 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <54D34CD6.6020401@lsces.co.uk> <585A6531-BFF1-4B40-9052-518518A9409F@ajf.me> <54D36322.8080805@lsces.co.uk> <54D372CD.5070007@gmail.com> <54D377AF.9030009@gmx.de> <54D37D09.6050803@gmail.com> <54D38380.2060509@lsces.co.uk> <54D3995B.4050308@gmail.com> <54D39F2C.9020001@lsces.co.uk>
In-Reply-To: <54D39F2C.9020001@lsces.co.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] hints and constraints
From: rowan.collins@gmail.com (Rowan Collins)

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]