Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81831
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.199 as permitted sender)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
In-Reply-To: <CAPhkiZy+q0wMyEHXPbWW+V-W+sLKHV9jKehggw-pS-j+PEXrPw@mail.gmail.com>
Date: Wed, 4 Feb 2015 18:21:14 +0000
Cc: Florian Margaine <florian@margaine.com>,
 Leigh <leight@gmail.com>,
 PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <85CB3199-8D44-4D34-9212-6E18D6BD7B73@ajf.me>
References: <CA+9eiLuueVvYgT-fhCvzBSxzoDioinpc5Eok5OQtGDBG1FZM=w@mail.gmail.com> <CAPwsocFD6sUEzo6uE4X0N2OF_N_eze5k+=f7Z+WyZHum7=MoeA@mail.gmail.com> <CABRjmp9a-ZfqWv3B4xh70LUEGFP4RpXgNwwYkRmnq9ST0y7CuQ@mail.gmail.com> <CAPhkiZy+q0wMyEHXPbWW+V-W+sLKHV9jKehggw-pS-j+PEXrPw@mail.gmail.com>
To: Andrey Andreev <narf@devilix.net>
Subject: Re: [PHP-DEV] What do we need strict scalar type hints for?
From: ajf@ajf.me (Andrea Faulds)

Hi again,

> On 4 Feb 2015, at 11:15, Andrey Andreev <narf@devilix.net> wrote:
>=20
> On Wed, Feb 4, 2015 at 1:02 PM, Florian Margaine =
<florian@margaine.com> wrote:
>> Hi Leigh,
>>=20
>> Le 4 f=C3=A9vr. 2015 11:50, "Leigh" <leight@gmail.com> a =C3=A9crit :
>>>=20
>>> What was wrong with:
>>>=20
>>> function x(int $y, string $z) { // strict
>>> function x((int) $y, (string) $z) { // casting
>>>=20
>>> This was the best suggestion I've seen that covers the requirements =
of
>>> both camps, and is still very clear how data is going to be handled.
>>>=20
>>> Authors who want their APIs to adhered to strictly can do that,
>>> authors who want to accept anything and have it end up as their
>>> desired type can do that too.
>>=20
>> Because it is then the callee who decides, not the caller, whether or =
not
>> he wants strict typing.
>>=20
>=20
> ... and apparently, this is the root of all evil. :)

It=E2=80=99s not =E2=80=9Cthe root of all evil". But the two-syntax =
approach has disadvantages I=E2=80=99ve elaborated numerous times.

It shifts the choice to the callee, not the caller. This means existing =
applications are broken if strict hints are added to existing libraries. =
It means that programmers will have to deal with two different systems, =
simultaneously, in the same file or function or method, because one API =
uses (int) and the other uses int. It means that if the API author =
decides to have weak types, you are prevented by the language from =
having the benefits of strict typing, even if you want them. It also has =
a syntax issue: (int) looks like an explicit cast, yet what is usually =
proposed doesn=E2=80=99t something similar. There=E2=80=99s also the =
consistency issue in that we=E2=80=99d have to support real for =
consistency with (real), since T_DOUBLE_CAST is a token. It means that =
internal functions could now also use strict hints - or if they can=E2=80=99=
t, we have a consistency issue. It means beginners, and people who =
don=E2=80=99t like strict types, now have to deal with strict types in =
their code, despite PHP always having been a weakly-typed, =
beginner-friendly language. And so on, and so forth.

The current RFC deliberately does not propose this because I think it =
causes more problems then it solves.=20

> I am baffled by how the two-syntaxes suggestion is always so easily
> dismissed by that argument. I'd argue that most people who support the
> current proposal don't fully understand what declare(strict_type=3D1)
> really does.

Well, *I* understand what it does. I=E2=80=99ve used it. It worked =
really, fantastically well=E2=80=A6 better than I expected it to. It =
provided benefits that the two-syntax suggestion wouldn=E2=80=99t have. =
It provided benefits that just strict hints wouldn=E2=80=99t have. It =
provided benefits that just weak hints wouldn=E2=80=99t have.

> As I've previously said - putting the caller in control
> (and really the caller, not in a per-file context) makes it a
> debugging tool, not support for strict typing.

What=E2=80=99s the difference between =E2=80=9Cper-file=E2=80=9D and =
=E2=80=9Creally the caller=E2=80=9D? The RFC *does* allow you to use =
declare() blocks if you really want to.

Also, type hints are mostly a debugging tool anyway. They=E2=80=99re a =
tool for catching errors early, and to enable better documentation. =
That=E2=80=99s all that they do.

--
Andrea Faulds
http://ajf.me/