Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83061
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain devilix.net designates 209.85.214.181 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <febeab4a178fa3bef2c84bdce1acc199@mail.gmail.com>
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>
	<febeab4a178fa3bef2c84bdce1acc199@mail.gmail.com>
Date: Wed, 18 Feb 2015 15:10:31 +0200
Message-ID: <CAPhkiZyA5EWfb6FsyCD611SPhafY0sf7tw4r-2J+CEj-XRN0hQ@mail.gmail.com>
To: Zeev Suraski <zeev@zend.com>
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 Zeev,

On Wed, Feb 18, 2015 at 2:31 PM, Zeev Suraski <zeev@zend.com> wrote:
>> 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.
>
> Thanks the example Andrey, it's helpful.
>
> My goal with asking for these use cases isn't to claim that they never
> exist, and I certainly don't want to get into a theological discussion.  My
> goal is to try and figure out whether many, if not all, proponents of strict
> typing would be willing to live with a compromise on single set of rules,
> that on one hand would be a lot stricter than what was proposed for weak
> typing in the v0.3 RFC (bool->anything fails, any string that's not strictly
> looking like a number incl. "100 dogs" -> int/float fails, float->int
> fails), but on the other hand, would allow certain lossless conversions
> (numeric string -> int/float, int->float, toString() to string, etc.) to
> work.
>

I didn't imply that you meant any of that, not in this thread anyway
... If I've done it previously, it's only because your choice of words
had made it appear that way. You don't need to defend yourself
everytime I quote you. :)

> When people from both schools of thought (strict/weak) come to evaluate this
> possibility, remember that we don't need a solution that works in 100.0% of
> the cases.  Edge cases, again, be them strict or weak, can always be
> implemented with a bit of custom code inside the function - the important
> thing is to get a system that addresses the vast majority of cases.
>

Well, that's usually the case because you simply can't provide a 100% solution.

In this case, I believe we can satisfy if not 100%, then 99% of the
use cases by simply providing both weak and strict hints
simultaneously. From my POV, further restricting conversion rules for
weak hints is deffinately an improvement, but still a limited one.
There's no *technical* limitation to including two solutions to the
problem, so I'd rather do that and be practical instead of following a
belief for what does or doesn't belong in PHP.

I know you're on the flip side, so we shall agree to disagree on that.

Cheers,
Andrey.