Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:80090
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.200 as permitted sender)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
In-Reply-To: <CADyq6sJ6vsrzjQuWzzo3Th4WULNhrh-e=F2o7j7t1FysS9aAkg@mail.gmail.com>
Date: Fri, 2 Jan 2015 13:00:37 +0000
Cc: Stanislav Malyshev <smalyshev@gmail.com>,
 Thomas Bley <mails@thomasbley.de>,
 Nikita Popov <nikita.ppv@gmail.com>,
 PHP Internals List <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <458FFDA4-032E-46D9-BE93-E7307F98A1E6@ajf.me>
References: <41D5BB0B-73AF-488E-968D-90B2878E3178@ajf.me> <CAF+90c-uiLj1QoT+dXfd1obRXNcYcpBAJ-aU59yEXk+HYNZRFw@mail.gmail.com> <20150101164402.EB1442605AB@dd15934.kasserver.com> <CADyq6sKN0PVdE5930YaSzZWkKwGM8SYbVrspzK_WL+7CRgK8hA@mail.gmail.com> <54A5DFCE.6030307@gmail.com> <CADyq6sJ6vsrzjQuWzzo3Th4WULNhrh-e=F2o7j7t1FysS9aAkg@mail.gmail.com>
To: Marco Pivetta <ocramius@gmail.com>
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hints
From: ajf@ajf.me (Andrea Faulds)

Hi Marco,

> On 2 Jan 2015, at 09:16, Marco Pivetta <ocramius@gmail.com> wrote:
>=20
>=20
> I'm not sure why everyone is still taking the PHP manual as a good =
reference about how to write software: PHP internal functions are one of =
the main reason why this language is under-appreciated.
>=20
> The manual is pulling the concepts of `int`, `string` and so on out of =
thin air, whereas the correct syntax in those cases is =
`int|string|Stringable`, with explicit explanation of what those strings =
should look like.

I don=E2=80=99t see why the manual is wrong. Yes, in a strictly-typed =
language which allows no conversion of arguments, foobar(int $foo) =
wouldn=E2=80=99t have the behaviour PHP exhibits. Yet PHP is not a =
strictly-typed language, and weakly-typed parameters are hardly a novel =
concept. The language that PHP is implemented in, C, also has this. And =
yet, C does not have this:

    void foobar(char|unsigned char|short|unsigned short|int|unsigned =
int|long|unsigned long|long long|unsigned long =
long|float|double|_Bool|void* foo)

Why? Because in C, implicit conversions between parameter types are =
permitted. PHP has the same thing for its internal/extension functions. =
The manual isn=E2=80=99t wrong.

> This is constraining. Constraining has nothing to do with validation =
and casting: mixing the concepts of type-juggling, validation and =
constraining is a huge mess (which I don't like, but it's better than =
having nothing), and it would better be off using a syntax like:

Argument types do not necessarily exist purely to error on invalid =
input. They also exist for documentation purposes and, in languages like =
C, implicit conversion.

>     public function __construct(ProductId $productId, (int) $amount)
>=20
> This makes the difference **much more clear**, as that `(int)` is not =
a constraint, it's a different, broader concept.

I don=E2=80=99t think the cast-like syntax is a particularly good idea. =
It=E2=80=99s inconsistent with our manual conventions (then again, many =
other things are). It=E2=80=99s misleading, as well: we don=E2=80=99t do =
an explicit cast. If it was an explicit cast, literally any value would =
be accepted. But that=E2=80=99s not the case at all, the weakly-typed =
parameters that extension functions have do not accept any value. =
Instead, they accept the desired type, and a limited range of =
convertible values of other scalar types.

> Additionally, the BC break concern of strict type-hinting and classes =
named `String`, `Int` and `Bool` (and similars) is delayed until we get =
strict type-hints, as the syntax is currently not allowed by the =
language and doesn't present any BC issues (http://3v4l.org/3Fqdh):

I=E2=80=99d rather not delay it. We probably should have reserved syntax =
for scalar hints ages ago.

> @Andrea: as for the "strict" and "non-strict" PHP suggestion you had =
before, please don't do that. Take following example:
>=20
> function repeat(int $amount, (string) $value) {
>     $acc =3D '';
>     $i =3D 0;
>=20
>     while ($i < $amount) {
>         $i +=3D 1;
>         $acc .=3D $value;
>     }
>=20
>     return $acc;
> }
>=20
> As you can see, mixing implicit cast and strict constraining behaviors =
is perfectly fine in this case, so please don't include contextual =
switches: that would be even worse IMO.

I don=E2=80=99t understand why that particular example makes sense. =
Since it=E2=80=99s producing a string value, surely $value should always =
be a string? I really don=E2=80=99t like the idea of mixing strong- and =
weakly-typed parameters. We should be consistent. Otherwise, we are =
imposing too high a mental burden on programmers, who will now need to =
remember which parameters are strongly-typed and which parameters are =
weakly-typed.

Thanks.

--
Andrea Faulds
http://ajf.me/