Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83055
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.223.170 as permitted sender)
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>
In-Reply-To: <CAPhkiZwb7+5wRdoT728nauiM1+rtjvLjOL6G6m7sCHYCHzp=4Q@mail.gmail.com>
MIME-Version: 1.0
Thread-Index: AQKz6wpj8b81mnwJq1LfxWbU4ZJyQgGjcksIAbrU1N8Bn0wufQGLyLi6AmixSwcCFGxi7gFUJDhrmsw+cBA=
Date: Wed, 18 Feb 2015 14:31:10 +0200
Message-ID: <febeab4a178fa3bef2c84bdce1acc199@mail.gmail.com>
To: Andrey Andreev <narf@devilix.net>
Cc: internals@lists.php.net
Content-Type: text/plain; charset=UTF-8
Subject: RE: [PHP-DEV] Scalar Type Hints v0.4
From: zeev@zend.com (Zeev Suraski)

> 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.

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.

Thanks!

Zeev