Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75598
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain fb.com does not designate 67.231.153.30 as permitted sender)
To: Andrea Faulds <ajf@ajf.me>
CC: Zeev Suraski <zeev@zend.com>, Rowan Collins <rowan.collins@gmail.com>,
        "internals@lists.php.net" <internals@lists.php.net>
Thread-Topic: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
Thread-Index: AQHPnj3hxlB2fkX7N0aer00oN4qWGJuf/3WAgAAJrwCAAAEEAIAAnU6AgAEDiQCAAB1pAIAAE5qAgAAnAACAAAFHgIAA5WOAgAAPkwCAAAs4gIAAFFEAgAAC3ACAABq3gIAATUAA
Date: Wed, 16 Jul 2014 18:39:54 +0000
Message-ID: <DE6B3E20-1F3C-4C25-A57B-1BD2C6232A13@fb.com>
References: <08503591-EFC8-48E6-984E-FFC292C5EA5F@ajf.me>
 <16D48604-0C0A-4613-91A4-21392E3A2636@ajf.me>
 <CAGAGxbZG+c46P4E2pmEHNnEv=4DyTrHOuXbZu3zAOSU3M6-A-A@mail.gmail.com>
 <05CE2216-C5D9-4937-9F2E-AA1407284D9F@ajf.me>
 <53C460DF.5040304@sugarcrm.com> <53C53A96.2040303@gmail.com>
 <53C55342.1010207@sugarcrm.com> <53C563B3.6060905@gmail.com>
 <CAPhkiZwvqW=d3Ayn-=Hx5HfkcOFB+gQ6rRoFThxA8hESK4WLrA@mail.gmail.com>
 <54536191-1B92-4933-973F-0C8289D13A4C@ajf.me>
 <00d12255efc53466245b21a83ff7d474@mail.gmail.com>
 <53C652FA.6010704@gmail.com>
 <d15e014a0b7a7a244c30b02c849ed7b3@mail.gmail.com>
 <53C66D6E.9060200@gmail.com>
 <60f496756412de6ad97751d91ead5058@mail.gmail.com>
 <B6D70B24-183A-4C62-A5E5-6ECDD9A8ECBA@ajf.me>
In-Reply-To: <B6D70B24-183A-4C62-A5E5-6ECDD9A8ECBA@ajf.me>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <6FE707E47F935A4ABA4F74B6CEC6D35A@fb.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
From: jwatzman@fb.com (Josh Watzman)

On Jul 16, 2014, at 7:03 AM, Andrea Faulds <ajf@ajf.me> wrote:

> On 16 Jul 2014, at 13:28, Zeev Suraski <zeev@zend.com> wrote:
>=20
>> It's more of a lossy cast, exactly as we have today, that has an
>> (effectively-optional-since-it's-off-by-default) to warn you about loss =
of
>> data.
>> For the vast majority of users who use the defaults, there'll be nothing=
 new
>> to learn except for the availability of those implicit casts in function
>> signatures.
>> For those who want to take advantage of 'loss protection', they'd have t=
o
>> learn about this extra warning type and clean their code so that it adhe=
res
>> to it.  But there too, they'd have consistency, just one set of rules fo=
r
>> implicit cast of scalar values across all of PHP.
>=20
> The problem with making this RFC do the lossy thing is it then removes on=
e key advantage of it: that this RFC provides a measure of strictness. With=
out that, we have no real compromise proposal, and we might as well introdu=
ce a second set of =93strict=94 type hints. The whole point of the current =
behaviour is that it compromises between the weak typing and strict typing =
camps; doing what zpp does is giving in to the former camp, and then it=92s=
 not a compromise any more, is it?

This is exactly why I really like this proposal. While I love the idea of s=
uper strict type annotations, I totally understand why they shouldn't be ad=
ded to PHP. The RFC as it stands strikes a great balance between keeping wi=
th "the PHP way" of weak typing, while still making scalar type annotations=
 useful.

If I'm writing an app and an API I'm using has been annotated to take an "i=
nt" parameter, and I pass something that cannot possibly be an int, I want =
to know that, I want to know it *now*, and I don't want the program to keep=
 executing (possibly writing bad data to a database or doing any number of =
other crazy things that could happen when my not-an-int gets converted to a=
n int). The entire utility of the type annotation there is that the API dev=
eloper has said "I expect an int here, if you don't pass one, you're not us=
ing the API correctly". As others have argued, the API could technically im=
plement the "lossless conversion" logic itself, but it's fiddly at best to =
get right, and very error-prone. In the other direction, if the API really =
does want a cast-to-int-no-matter-what, it can just omit the type annotatio=
n and do that -- it's easy and not at all error-prone.

I understand the argument about consistency, but I think this can be mitiga=
ted if you couch the feature correctly when documenting it, announcing it, =
etc, so that people get the right mental model in their heads when they fir=
st hear about it. I wouldn't talk about the type annotations this RFC propo=
ses in terms of casts, since they aren't really quite casts (as the folks m=
aking the consistency argument have stated). They're something else -- they=
're type annotations (or type hints, or whatever you want to call them). In=
 that vein, they are *consistent* with the existing strict enforcement of o=
bject type annotations, with the added detail that "strict enforcement" for=
 scalars is defined in terms of "lossless conversion" as outlined in the RF=
C, since that's the "PHP way" of loosely dealing with scalar types. The ide=
a of "lossless conversion" has just never been relevant before since there =
is no such thing as a lossless conversion to any object type, or from any t=
ype to an array -- but it's a completely consistent way of extending the wa=
y we deal with the existing annotations. (And not inconsistent with casts s=
ince it isn't a cast!)

Josh Watzman