Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83455
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.214 cause and error)
Message-ID: <54E93263.2030601@lsces.co.uk>
Date: Sun, 22 Feb 2015 01:35:31 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: francois@php.net, internals@lists.php.net
References: <7ef509ef10bb345c792f9d259c7a3fbb@mail.gmail.com>	<CAAyV7nHq_-9jyRcwJmiAxthmEo3u3MDXcyOC09LV2DETABzCoA@mail.gmail.com>	<c8b54c9828154c7e07810461db03bd4d@mail.gmail.com> <CALwr1GmzNOFUgZGxC+vRri6btdh=QQaUnE+d0Wr8XLbQOEuMmQ@mail.gmail.com> <54E91123.9010508@lsces.co.uk> <066d01d04e33$82dca020$8895e060$@php.net>
In-Reply-To: <066d01d04e33$82dca020$8895e060$@php.net>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Coercive Scalar Type Hints RFC
From: lester@lsces.co.uk (Lester Caine)

On 22/02/15 00:07, François Laupretre wrote:
>>> 3. "1E07" might be construed as overly generous assuming we are
>>> > > excluding stringy integers like hex, oct and binary
>> > Yet again ... If we have to add a lot of extra checks then why can't we
>> > simply ask if the data is a usable integer. At the end of the day it
>> > does depend on where the data was sourced? Binary data is only usable if
>> > we know that it is binary, or we will be converting some other format
>> > anyway?
> I asked you for rules to recognize octal. I am all in favor of recognizing other numeric strings, hexa with leading 0x (detecting trailing h is more ambiguous and slower), for instance. It was removed some weeks ago for consistency reasons but it can be reintroduced in a consistent way in the future if needed.

I've given the 'c' ones, but others have already blocked the use of
them. Octal escape is allowed but a simple '0' or '0o' has the same
problem as 0h or 0x ? Those of us still using 'c/c++' get used to the
old standards.

>>> > > 4. I'm assuming the stringy ints are rejected?
>> > Source material may be 'stringy ints', so all that does is say "we can't
>> > use the original variable it has to be converted" rather than we can and
>> > use it's 'non-stringy' view.
> Can you explain? I don't understand.

I'm working with a 'variable' which may be an integer but that is only
enforced by reference to how I am looking at it. I understand that some
people want to ONLY allow it to be an integer and that may be the
constraint added to it, but you may also need the string view, or the
origin may be a string already, so one maintains both a binary view and
a 'string' view of the same variable. So I don't subscribe to 'stringy
ints' because all variables have a stringy element naturally.

If I had any need for 'strict' constraints on a variable it has to cover
both the size and type of the data, simply saying int is of little use
if the data is too big anyway.

-- 
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