Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75415
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.216 as permitted sender)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
In-Reply-To: <63e5b1c38d6e0c5111987e78d9b59be3@mail.gmail.com>
Date: Sun, 13 Jul 2014 16:19:07 +0100
Cc: Jocelyn Fournier <jocelyn.fournier@gmail.com>,
 PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <E2926DD2-B0AE-4A87-BEA8-F07FE49CE4B5@ajf.me>
References: <08503591-EFC8-48E6-984E-FFC292C5EA5F@ajf.me> <CAF+90c-ojALBgeyXu+f2tW6LoW8+4XGVpu_+i9SyX=u4RSoxug@mail.gmail.com> <027E65EF-C4FC-474C-92BB-D99EFADDEEED@ajf.me> <ada4093ad61814c182f8ca31939962ea@mail.gmail.com> <BDC11A4E-0610-49A3-B8AE-E9D3627B75C8@ajf.me> <eab1ceea2084415d21736a69c4ac6fdc@mail.gmail.com> <53C29EE4.3090808@gmail.com> <63e5b1c38d6e0c5111987e78d9b59be3@mail.gmail.com>
To: Zeev Suraski <zeev@zend.com>
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
From: ajf@ajf.me (Andrea Faulds)


On 13 Jul 2014, at 16:01, Zeev Suraski <zeev@zend.com> wrote:

>> =46rom my point of view, if the type annotations are doing implicit =
cast
>> (with or
>> without E_NOTICE/E_STRICT warning), they should behave exactly the =
same
>> than an explicit cast. If it behaves differently, I'll be really =
difficult
>> for a
>> developer to guess what will be the PHP behaviour with this new =
syntax.
>=20
> Coming to think of it, this is probably the cleanest and most =
productive
> approach.  +1.

If we interpret that to mean just casting everything with no error =
cases, but E_NOTICE on some, then it is one of the three main proposals =
suggested for scalar type hinting:

1. Casting type hints
2. Strict type hints
3. Scalar type hinting with casts

(There are others, but I won=92t talk about them)

I=92m not of the opinion that the first option, where we just cast and =
never error, is ideal. It does ensure the values are of the correct type =
when they get to you, so it keeps PHP=92s type juggling, but it is =
unlikely to catch bugs where the wrong value has been passed.

The second option, while appealing to some, goes completely against =
PHP=92s type juggling. You=92d have to manually cast everything =
yourself. As I understand it, this is essentially what Hack does, but =
PHP is not Hack and I don=92t really think this is a good idea.

A fourth option would be to allow both by using different syntaxes for =
casting and strict, but I don=92t think we should add two different ways =
because we can=92t agree; we should do it just one way.

The final option, which this RFC proposes, is something of a compromise =
between the two proposals. I think it=92s sufficiently strict to prevent =
bugs, and the parameter will be the right type, but it does not stop =
type-juggling.

Nikita wrote about the subject of the different approaches here in 2012: =
http://nikic.github.io/2012/03/06/Scalar-type-hinting-is-harder-than-you-t=
hink.html

However, I don=92t propose =93strict weak=94 typing, I propose this RFC.

--
Andrea Faulds
http://ajf.me/