Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83057
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain devilix.net designates 209.85.214.171 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <030901d04b76$4a1fb340$de5f19c0$@php.net>
References: <CAESVnVoZYiMWQk1Ydc-9wbkJo7Ru_4mrUtrubW=Rh=QKK9o8TA@mail.gmail.com>
	<CAF+90c_S3xT07F-4smHeD=BTuSG9VQZxZ==mhyOzDuBw5QPX_Q@mail.gmail.com>
	<54E3E27B.2010903@lerdorf.com>
	<CAF+90c8o8GtO9=7JJ3Jmjzg-=qVAD1aiQaU32joOeD6XH_f4hg@mail.gmail.com>
	<2f99c47df51fa6c73131032ec50fade0@mail.gmail.com>
	<CAPhkiZxvJda-Q1WEr7LTrX9BCHKs0QapQ8f=hh8L+1SNC+KFHQ@mail.gmail.com>
	<030901d04b76$4a1fb340$de5f19c0$@php.net>
Date: Wed, 18 Feb 2015 14:45:12 +0200
Message-ID: <CAPhkiZxO_Zp7sTUBoj2m1L1yjCrUS=TC1i_yAw=Ak6mr=1kYMg@mail.gmail.com>
To: francois@php.net
Cc: Zeev Suraski <zeev@zend.com>, Nikita Popov <nikita.ppv@gmail.com>, 
	Rasmus Lerdorf <rasmus@lerdorf.com>, Sara Golemon <pollita@php.net>, 
	PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Scalar Type Hints v0.4
From: narf@devilix.net (Andrey Andreev)

Hi,

On Wed, Feb 18, 2015 at 2:27 PM, Fran=C3=A7ois Laupretre <francois@php.net>=
 wrote:
> Hi Andrey,
>
>> De : Andrey Andreev [mailto:narf@devilix.net]
>>
>> I too am curious about the potential issue with "123" to 123
>> specifically, although it could be seen as a subset of another problem
>> that is solved with strict hints - numeric-character string
>> identifiers being erroneously treated as integers.
>
> Please give use cases. Do you want to support '0xhexa' strings ? that's p=
ossible. We are not only restricting possible conversions, we can also supp=
ort additional syntaxes. Just give use cases for what you think should be e=
nabled or disabled, compared to the current behavior.
>
> The only change we have in list so far about (string -> number) is reject=
ing trailing chars (but accepting trailing blanks).
>
> We are in the process of changing these rules so, please give examples of=
 ' numeric-character string identifiers being erroneously treated as intege=
rs'. If you mean '7 years', it's in list already. If others, tell us.
>
>> That is especially bad when such identifiers are in fact generated as
>> integers first so that they are incremental, but the
>> program/database/business logic requires them to be fixed-length
>> strings and/or in hexadecimal format. In such cases, even silently
>> discarding leading zeros can prove to be problematic, while in the
>> case of hexadecimal representations you'd need more than 10 data
>> samples to notice the problem if you don't use a strict hint.
>
> Do you mean we should accept hexadecimal string as int ? why not ? Give e=
xact syntax(es) you want to support (except leading/trailing blanks, which =
are default now).
>

No, I meant the opposite ... I was trying to explain cases where a
weak hint would be insufficient. Sorry for not including examples in
my first mail, I did that in my next reply:

> Consider the following signature:
>
>     function foo(int $bar) {}
>
> In the case of a *string* representation of a hexadecimal number, the
> following would error only on the last iteration with a weak hint, and
> on the very first if it was a strict hint:
>
>     for ($i =3D 0; $i < 11; $i++)
>     {
>         foo(base_convert($i, 10, 16));
>     }
>
> And when I said leading zeros, I was talking about fixed-length string
> identifiers such as '001', '002', etc. where you may *unintentionally*
> pass such a value to a function that deals with ... quantities, for
> example. A strict hint in that case would immediately catch this
> logical error while a weak hint would silently ignore the leading
> zeros and will happily treat the value as an integer. Again, the
> precondition here is that it's not an integer value that happens to be
> stored as a string, but a non-integer value that just looks like an
> integer.

Cheers,
Andrey.