Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81613
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.208 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: <CAPhkiZxaLrZR92FabwP2EWuH2OrprrxOzPVezOoiET77Bao4_g@mail.gmail.com>
Date: Mon, 2 Feb 2015 17:00:08 +0000
Cc: Derick Rethans <derick@php.net>,
 Dmitry Stogov <dmitry@zend.com>,
 PHP Internals List <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <06F03121-9CC1-48B8-87CF-8E5A43921548@ajf.me>
References: <8DCD1B72-C81D-499E-B455-E4A042CD76E6@ajf.me> <B0C5801F-7D46-4CB0-9B2E-AF18C44DAF14@ajf.me> <CA+9eiLtPVoDYT71fYrZfxPk6a_m7ErFd2w8UBvu9ZeTEbnm4kA@mail.gmail.com> <alpine.DEB.2.11.1502021635000.16838@whisky.home.derickrethans.nl> <6C58B302-C78A-490B-A333-4D1A71334E19@ajf.me> <CAPhkiZwUBs5xwb5KfcVinoLDh7C2qOPD76bJAxVOnzN1hx_9WQ@mail.gmail.com> <C1C3BCF2-72B8-4B5E-AD57-E419220DDF05@ajf.me> <CAPhkiZxaLrZR92FabwP2EWuH2OrprrxOzPVezOoiET77Bao4_g@mail.gmail.com>
To: Andrey Andreev <narf@devilix.net>
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2
From: ajf@ajf.me (Andrea Faulds)

Hi Andrey,

> On 2 Feb 2015, at 16:57, Andrey Andreev <narf@devilix.net> wrote:
>=20
> On Mon, Feb 2, 2015 at 6:52 PM, Andrea Faulds <ajf@ajf.me> wrote:
>> Hi Andrey,
>>=20
>>> On 2 Feb 2015, at 16:48, Andrey Andreev <narf@devilix.net> wrote:
>>>=20
>>> As already said, we're just going around in circles at this point, =
but
>>> a migration issue?
>>>=20
>>> Whatever code using the scalar type hints should be *new* code in
>>> userland.
>>=20
>> Why not existing userland code? If only new code adds type hints, the =
ability to detect errors in code is severely curtailed. That would be =
really unfortunate.
>>=20
>>> You're basing your whole argument on the assumption that all
>>> internal functions would break with strict=3D1 ... nobody needs that =
and
>>> it doesn't have to be done.
>>=20
>> I wasn=E2=80=99t talking about internal functions=E2=80=A6 I=E2=80=99m =
talking about userland code in the hypothetical case that we added =
strict-only hints.
>>=20
>> I don=E2=80=99t see where you=E2=80=99ve gotten that impression from.
>>=20
>=20
> Well ... existing userland code doesn't have scalar type hints, it
> couldn't possibly do. How can you have migration issues with it?

I=E2=80=99ll just quote my previous message:

> One of the nice things about strict mode only applying to code which =
asks for it, is that if a function if an API has type hints added, it =
won=E2=80=99t suddenly break calling code that didn=E2=80=99t strictly =
match types, if that calling code uses the default weak mode behaviour =
(which it will if it was written pre-PHP 7).
>=20
> For example, say I have some sort of Response object that lets you set =
a body:
>=20
>    class Response {
>        public function setBody($message);
>    }
>=20
> In PHP 5, it=E2=80=99s perfectly fine to pass something that=E2=80=99s =
not a string for $message:
>=20
>    $foo =3D new Response;
>    $foo->setBody(67);
>=20
> Absurd example, but this sort of thing does happen in real world code, =
often accidentally.
>=20
> Now, let=E2=80=99s say we add a string type hint in a new version of =
the library:
>=20
>    interface Response {
>        public function setBody(string $message);
>    }
>=20
> If PHP=E2=80=99s type hints were always strict, then our existing PHP =
5 code from earlier that took advantage of PHP=E2=80=99s weak typing =
would now produce an error:
>=20
>    Catchable fatal error: Argument 1 passed to Response::setBody() =
must be of the type string, integer given
>=20
> This isn=E2=80=99t good - it makes migration of the existing codebase =
difficult.
>=20
> Weak typing solves this problem because it allows conversions. =
However, it=E2=80=99s not really good that the code was passing an =
integer in the first place - it should really be passing a string.
>=20
> The solution, then, is what this RFC offers. By default, weak typing =
is used, so your existing code doesn=E2=80=99t break initially. But once =
you=E2=80=99ve added type hints in a few places, you can switch to =
strict typing, and that error will be detected and can be fixed.
>=20
> This way, we can have stricter types without sacrificing compatibility =
or complicating migration.


Basically, strict-only types complicates their addition to existing =
codebases, including libraries.

What this RFC proposes is similar to Hack=E2=80=99s gradual typing, in a =
sense, in that it allows you to gradually add types to your codebase =
without breaking things.

--
Andrea Faulds
http://ajf.me/