Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80050
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=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
In-Reply-To: <CAF+90c-uiLj1QoT+dXfd1obRXNcYcpBAJ-aU59yEXk+HYNZRFw@mail.gmail.com>
Date: Thu, 1 Jan 2015 15:33:41 +0000
Cc: PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <C0E1AD78-1275-4C0D-81DE-7EF4399216C8@ajf.me>
References: <41D5BB0B-73AF-488E-968D-90B2878E3178@ajf.me> <CAF+90c-uiLj1QoT+dXfd1obRXNcYcpBAJ-aU59yEXk+HYNZRFw@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hints
From: ajf@ajf.me (Andrea Faulds)

Hey Nikita,

> On 1 Jan 2015, at 14:05, Nikita Popov <nikita.ppv@gmail.com> wrote:
>=20
> While in favor of introducing scalar type annotations, I'm against =
this proposal in particular. I've held a different position in the past, =
but by now I'm thoroughly convinced that if we introduce scalar type =
declarations, they should be strict. No wiggling, no casting.
>=20
> Apart from being consistent with the existing behavior of type =
declarations and being what the majority of the vocal community wants, =
it is also possible to reason about strict type declarations statically.
>=20
> This means that an IDE or other tool will be able to perform =
meaningful analysis based on typehinted functions. E.g. if you pass the =
result of a string function to an int parameter, your code is definitely =
wrong and you can be told so. Loose typehints as proposed here do not =
offer this possibility, because a string can be or can not be a valid =
input to an int parameter depending on the exact value.
>=20
> For the same reason loose typehints are also more fragile. Code that =
worked in casual testing during development will fail in production when =
unexpected, improperly validated user input is encountered. With strict =
types on the other hand it is very likely that code working with one =
input will also work with all other possible inputs, because the type =
check is not value-dependent. (Types are typically much less volatile =
than values.)
>=20
> The ability to statically check type annotations is rather important =
to me. I think much of the usefulness of this feature would be lost =
without the ability to check correct usage with tooling. I'd also like =
to point out that Hack uses a strict type scheme and it seems to work =
well there (though I do acknowledge that the situation is not the same, =
as Hack has a generally more powerful and fully statically checked type =
system).
>=20
> Apart from these general thoughts, I also think that this proposal is =
a regression from the previous one. In the name of "consistency" it uses =
the rather weak zpp validation rules, which allow a lot of questionable =
input. Just look at the conversion table in the RFC, practically all of =
it is "Yes". I understand the motivation to reduce the number of =
different conversion semantics, but I just can't get behind it if it =
means reusing existing, bad conversion rules.

I would respond with something novel, but I notice now that your email =
is exactly the same as your comment on reddit, and there=E2=80=99s =
little point in responding to the same thing twice. So, for that reason, =
I=E2=80=99ll just reproduce my response on reddit, with some minor =
edits:

> I'm likely -1 on this proposal. I've held a different position in the =
past, but by now I'm thoroughly convinced that if we introduce scalar =
typehints, they should be strict.

Why are you opposed to adding non-strict type hints? I realise that =
strict type hints are desirable for certain reasons, but they fit very =
poorly with the rest of the language and are unlikely to ever make it =
into PHP. So why, then, oppose the addition of non-strict hints? Surely =
these hints, which offer many (albeit not all) of the benefits of strict =
hints, are far better than nothing?

> Apart from being consistent with the existing behavior of typehints

This RFC is consistent with the existing behaviour of extension =
functions (which match all userland type hints in behaviour). Besides, =
strict hints would be inconsistent with the rest of the language. PHP =
has never been strict for scalar types, and I think they'd make a rather =
awkward fit for that reason.

> , it is also possible to reason about strict typehints statically.

> This means that an IDE or other tool will be able to perform =
meaningful analysis based on typehinted functions. E.g. if you pass the =
result of a string function to an int parameter, your code is definitely =
wrong and you can be told so. Loose (casting) typehints do not offer =
this possibility, because a string can be or can not be a valid input to =
an int parameter depending on the exact value.

You have a point there. Unfortunately, casting hints prevent certain =
types of validation. However, some type combos always work and some =
always don't, so you can still error for certain cases (NULL, array, =
resource, or object where scalar expected).

While they do prevent certain types of validation, they don't prevent =
optimisations, so HHVM (and perhaps Zend in future) can still benefit =
from the type information.=20

> For the same reason loose typehints are also more fragile. Code that =
worked in casual testing during development will fail in production when =
unexpected, improperly validated user input is encountered.

This is also true to an extent, but it is alleviated partly if code is =
fully type hinted. If your entire codebase has type hints, such errors =
can be caught early before they're passed to other functions. Once =
values are converted to integers, they stay integers (unless you pass it =
to something taking a string).

Thanks.
--
Andrea Faulds
http://ajf.me/