Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83039
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain devilix.net designates 209.85.214.173 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <54E46171.3010805@lsces.co.uk>
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>
Date: Wed, 18 Feb 2015 12:51:02 +0200
Message-ID: <CAPhkiZwb7+5wRdoT728nauiM1+rtjvLjOL6G6m7sCHYCHzp=4Q@mail.gmail.com>
To: Lester Caine <lester@lsces.co.uk>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Scalar Type Hints v0.4
From: narf@devilix.net (Andrey Andreev)

Hi,

On Wed, Feb 18, 2015 at 11:54 AM, Lester Caine <lester@lsces.co.uk> wrote:
> On 18/02/15 09:14, Andrey Andreev wrote:
>> 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.
>> Obviously, that would be solved with automated testing, but
>> unfortunately even code with high test coverage % often lacks depth in
>> its test cases.
>
> Octal is something that can often be miss converted since it IS the same
> as an integer with only a '0' in front in PHP. But that is not something
> that can be fixed with the current proposals? Again we have to ensure
> that the pre-processing takes care of the problem and how would static
> analysis even know there was a problem? A type hint following the SQL
> standards would be more helpful than the javascript approach of giving
> an error in strict mode.
>

I'm not talking about octal, and nobody's talking about SQL here.

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 = 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.