Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81616
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain devilix.net designates 209.85.215.54 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <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>
	<06F03121-9CC1-48B8-87CF-8E5A43921548@ajf.me>
Date: Mon, 2 Feb 2015 19:09:47 +0200
Message-ID: <CAPhkiZxfQNEgJbKaP7GBAjuR3nkb6Nv_7PWPgqwrrxzBChUtkQ@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: Derick Rethans <derick@php.net>, Dmitry Stogov <dmitry@zend.com>, 
	PHP Internals List <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2
From: narf@devilix.net (Andrey Andreev)

On Mon, Feb 2, 2015 at 7:00 PM, Andrea Faulds <ajf@ajf.me> wrote:
> Hi Andrey,
>
>> On 2 Feb 2015, at 16:57, Andrey Andreev <narf@devilix.net> wrote:
>>
>> On Mon, Feb 2, 2015 at 6:52 PM, Andrea Faulds <ajf@ajf.me> wrote:
>>> Hi Andrey,
>>>
>>>> On 2 Feb 2015, at 16:48, Andrey Andreev <narf@devilix.net> wrote:
>>>>
>>>> As already said, we're just going around in circles at this point, but
>>>> a migration issue?
>>>>
>>>> Whatever code using the scalar type hints should be *new* code in
>>>> userland.
>>>
>>> Why not existing userland code? If only new code adds type hints, the a=
bility to detect errors in code is severely curtailed. That would be really=
 unfortunate.
>>>
>>>> You're basing your whole argument on the assumption that all
>>>> internal functions would break with strict=3D1 ... nobody needs that a=
nd
>>>> it doesn't have to be done.
>>>
>>> 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-o=
nly hints.
>>>
>>> I don=E2=80=99t see where you=E2=80=99ve gotten that impression from.
>>>
>>
>> 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 ask=
s 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 type=
s, if that calling code uses the default weak mode behaviour (which it will=
 if it was written pre-PHP 7).
>>
>> For example, say I have some sort of Response object that lets you set a=
 body:
>>
>>    class Response {
>>        public function setBody($message);
>>    }
>>
>> In PHP 5, it=E2=80=99s perfectly fine to pass something that=E2=80=99s n=
ot a string for $message:
>>
>>    $foo =3D new Response;
>>    $foo->setBody(67);
>>
>> Absurd example, but this sort of thing does happen in real world code, o=
ften accidentally.
>>
>> Now, let=E2=80=99s say we add a string type hint in a new version of the=
 library:
>>
>>    interface Response {
>>        public function setBody(string $message);
>>    }
>>
>> 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 no=
w produce an error:
>>
>>    Catchable fatal error: Argument 1 passed to Response::setBody() must =
be of the type string, integer given
>>
>> This isn=E2=80=99t good - it makes migration of the existing codebase di=
fficult.
>>
>> 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 fi=
rst place - it should really be passing a string.
>>
>> 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 typi=
ng, and that error will be detected and can be fixed.
>>
>> This way, we can have stricter types without sacrificing compatibility o=
r complicating migration.
>
>
> Basically, strict-only types complicates their addition to existing codeb=
ases, 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 withou=
t breaking things.
>

Eh ... sorry for not mentioning that in the same mail, but I've never
suggested a strict-only approach.

Cheers,
Andrey.