Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83066
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain devilix.net designates 209.85.214.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <030e01d04b7b$33bcdba0$9b3692e0$@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>
	<54E46171.3010805@lsces.co.uk>
	<CAPhkiZwb7+5wRdoT728nauiM1+rtjvLjOL6G6m7sCHYCHzp=4Q@mail.gmail.com>
	<030e01d04b7b$33bcdba0$9b3692e0$@php.net>
Date: Wed, 18 Feb 2015 15:31:35 +0200
Message-ID: <CAPhkiZydZ2PK7Ot3uwLJ5JXLcueMEWkNcSEmcVCYOjNCbe92-g@mail.gmail.com>
To: francois@php.net
Cc: Lester Caine <lester@lsces.co.uk>, "internals@lists.php.net" <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 Fran=C3=A7ois,

On Wed, Feb 18, 2015 at 3:02 PM, Fran=C3=A7ois Laupretre <francois@php.net>=
 wrote:
>> De : Andrey Andreev [mailto:narf@devilix.net]
>>
>> 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));
>>     }
>
> You're right. An hexa string with no leading '0x' and containing decimal =
digits only cannot be recognized as hexa. But I keep thinking that, balanci=
ng pros and cons, it's not enough to justify strict mode. Maybe I'm wrong a=
nd additional use cases will make me change my mind, but I consider hexa wi=
th no prefix as an edge-case.
>
> I don't say that's the right solution but the problem can be solved at th=
e base_convert() level. If we support '0x' strings as hexadecimal numbers, =
it can generate the '0x' prefix, which removes ambiguity for PHP and any ot=
her software that would have to interpret the string. Unfortunately, it wou=
ld probably have to be explicitly required through an option because of BC.=
 No perfect solution here.
>

In real-world applications, base_covert() would hardly ever be the
culprit and I don't want to change its current behavior. I only used
base_convert() in the example because that allowed the least amount of
code written to display the problem.

> Another argument some may consider weak : I'm also afraid that, in your e=
xample, the user seeing an error raised by strict mode could change its cod=
e to 'foo((int)base_convert', definitely hiding the real bug, even for 11 a=
nd up. So, Rasmus is right when he says strict mode can sometimes and indir=
ectly be counter-productive. Debugging shouldn't be considered as error sup=
pression only, but it is the case more than often.
>

Sorry, but I do consider that to be a weak argument ... We can't help
users who's only concern is eliminating error messages, we can only
help those that understand them.

Cheers,
Andrey.