Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80550
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.207 as permitted sender)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
In-Reply-To: <a939cd800e7472c135b4b0e5cc99e683@mail.gmail.com>
Date: Thu, 15 Jan 2015 15:27:55 +0000
Cc: RQuadling@gmail.com,
 Leigh <leight@gmail.com>,
 PHP Internals List <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <9DF6A860-203B-4ED7-A871-1F525A93E889@ajf.me>
References: <8DCD1B72-C81D-499E-B455-E4A042CD76E6@ajf.me> <CAPwsocGyv7dp8n=_E1QfrXRSbYZXcHZAPk5F=hDLB070i=SCGA@mail.gmail.com> <4E2073DE-0951-498C-97BB-DDAC094F11FA@ajf.me> <9a033dd1f223f854e760924d118ab812@mail.gmail.com> <CAKUjMCU-57cDpG5ZbDGv10dSqx=Ey40D-WbKxKSnC6oSYOfLWw@mail.gmail.com> <2ae0164cb9b9bf1c974d7a3c60af0466@mail.gmail.com> <F3BC55CD-38CD-42B7-AE0B-A6D34E3D3875@ajf.me> <6105ea99002e634373c09685310e26a6@mail.gmail.com> <D39D18B9-A9E5-430E-B00A-E0DE03DAFE8C@ajf.me> <e131f1aaf3ae0491f958171df36211f5@mail.gmail.com> <85F6139E-6332-4645-91B8-C852B07EA62A@ajf.me> <a939cd800e7472c135b4b0e5cc99e683@mail.gmail.com>
To: Zeev Suraski <zeev@zend.com>
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2
From: ajf@ajf.me (Andrea Faulds)

Hi Zeev,

> On 15 Jan 2015, at 15:10, Zeev Suraski <zeev@zend.com> wrote:
>=20
>> Let=E2=80=99s have a look. =46rom a quick skim over the thread for =
v0.1:
>>=20
>> * In favour of weak types (or the RFC anyway): Adam, Stas, yourself,
>> Jordi,
>> Pierre,
>=20
> You're definitely missing Dmitry (which helped with the RFC) as well =
as
> Xinchen and Arvids from today.  =46rom past experience I believe =
Rasmus too.

Yeah, I=E2=80=99m probably missing one or two from skimming over the =
previous RFC thread.

>> * Against, in favour of strict types: Maxime, Nikita, Markus, Marco,
>> Leigh,
>> Levi, Sven(?)
>=20
> As far as I recall (maybe I'm wrong) the only one here that outright =
opposed
> was Nikita.  Others suggested ways to improve it but didn't really =
oppose
> it.

Maybe. I don=E2=80=99t think Nikita was the only one opposed, but I may =
be wrong.

>> It is very clear to me that a lot of people would like strict types, =
and
>> some
>> people would like weak types. As to their relative numbers, I cannot =
say.
>=20
> Well, that's clear bias right here too - 'a lot' vs. 'some'.  Again, I =
don't
> think you have a way of knowing it and based on my experience the =
opposite
> is true - but none of us truly knows.  Either way, the former goes =
against
> what we created PHP around, while the latter does not.

Tradition isn=E2=80=99t everything.

>=20
>> I don=E2=80=99t think it=E2=80=99s really fair to cover only the use =
case of one half of
>> the PHP
>> community. The other half counts too. This is a rather divisive =
issue.
>=20
> I disagree.  PHP has never been about everything and the kitchen sink. =
 Not
> only do we not strive to support everyone's taste, we actually try not =
to,
> and be somewhat opinionated on how things should be done.
> This issue is primarily divisive among the inner core of the PHP =
userbase,
> hardly around the millions of users out there.

Supporting strict types isn=E2=80=99t =E2=80=9Ceverything and the =
kitchen sink=E2=80=9D. Sure, we do not need to cater to everyone=E2=80=99s=
 taste. But we shouldn=E2=80=99t do things which are unpopular, and weak =
types, depending on who you talk to, would be that. Strict types have a =
lot of support from parts of the community.

>> I don=E2=80=99t think this is true: if we are making a feature less =
useful (and
>> therefore
>> making many people avoid it), it=E2=80=99s worth considering if that =
is a problem.
>> If
>> we can easily cover the vast majority of people=E2=80=99s use cases, =
rather than
>> catering to only one group of people (who may or may not be the =
majority),
>> why don=E2=80=99t we?
>=20
> For the same reason we didn't introduce strict types in the countless =
times
> it came up in the past - it goes against the language's principles.

It is not necessarily in conflict. We have, after all, had strict typing =
for non-scalars for, what, a decade now?

>> Except that is not the case for this proposal, which explicitly and
>> deliberately
>> prevents the directive affecting inclusion. The behaviour is =
impossible to
>> toggle at runtime, unless you=E2=80=99re using some weird extension =
which lets you
>> edit the flag on the ZEND_DO_FCALL opcode.
>=20
> Fact is that people who run websites where they don't care about =
strict
> typing, can end up viewing strict type failures coming from code they =
don't
> own, which would make the app fail 'catastophically' and =
unpredictably.

That can happen in any case. Failures in libraries will always cause =
problems for users. If the library is broken, the user is screwed =
anyhow, there=E2=80=99s very little they can do about it.

> You'd have no way to turn it off (without diving to and changing the =
file in
> question) - because it's the code itself that turns it on - and from =
the
> user's point of view, for all practical purposes, at runtime.

In what way is it =E2=80=9Cat runtime=E2=80=9D? It=E2=80=99s a per-file =
setting. What it does is no different from manual assertions on each =
line of code.

=E2=80=9CRuntime=E2=80=9D implies something that can actually be changed =
at, well, runtime. This can=E2=80=99t.

Are you opposed to people using type assertions in their own code (not =
entirely uncommon) along the same lines? The following two code snippets =
are essentially equivalent:

    declare(strict_typehints=3DTRUE) {
        foo($bar, $baz); // foo() takes an integer and a string
    }

vs.

    if (!is_int($bar)) {
       throw new Exception(=E2=80=9CNot an integer=E2=80=9D);
    }
    if (!is_string($baz)) {
       throw new Exception(=E2=80=9CNot a string=E2=80=9D);
    }
    foo($bar, $baz);

It is a property of the code, it=E2=80=99s not =E2=80=9Cat runtime=E2=80=9D=
.

Heck, if code in a library that you=E2=80=99re using breaks because of =
strict hints, you probably can=E2=80=99t fix it anyway because something =
was probably seriously wrong.

--
Andrea Faulds
http://ajf.me/