Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81597
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: <CA+9eiLv3YUdvvo7NbkMOoJEb4eVUyoHEYzoAPweJp3FXVfFNMQ@mail.gmail.com>
Date: Mon, 2 Feb 2015 16:30:42 +0000
Cc: PHP Internals List <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <5175DE01-ADC9-4A0B-8343-820C53B30054@ajf.me>
References: <8DCD1B72-C81D-499E-B455-E4A042CD76E6@ajf.me> <B0C5801F-7D46-4CB0-9B2E-AF18C44DAF14@ajf.me> <CA+9eiLtPVoDYT71fYrZfxPk6a_m7ErFd2w8UBvu9ZeTEbnm4kA@mail.gmail.com> <1E54E93F-8CE1-469F-BE1F-DD2F1DF76E39@ajf.me> <CA+9eiLv3YUdvvo7NbkMOoJEb4eVUyoHEYzoAPweJp3FXVfFNMQ@mail.gmail.com>
To: Dmitry Stogov <dmitry@zend.com>
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2
From: ajf@ajf.me (Andrea Faulds)

Hi Dmitry,

> On 2 Feb 2015, at 09:24, Dmitry Stogov <dmitry@zend.com> wrote:
>=20
> > Will we able to call the same function using weak
> > type hinting from on file and with strict from the other?
>=20
> Yes, for the parameter type hints anyway. That means that strict and =
weak code is interoperable without enforcing a model on each other.
>=20
> At first I thought, this is ugly solution. Now I'm not completely =
sure.

I did as well when I first saw the idea proposed (someone else =
originally suggested it). It does seem ugly on the surface, but it has =
some advantages. Sure, you have to add this extra line of code to each =
file, that=E2=80=99s annoying. But, it means full =
backwards-compatibility, easier migration of existing codebases, and =
most importantly, allows people to choose one mode or another without =
affecting other users that have to call their code.

> I see, but this would require declare(strict_types=3D1) everywhere =
that would turn PHP into Java.

Well, not quite Java, but yes. Typing it out is annoying. But it=E2=80=99s=
 better than implicit strict typing for a directory, and it means we =
avoid having two or three different kinds of scalar type hint, so =
there=E2=80=99s no mixing of systems within the same file.

After a while I think people will get used to it. PHP programmers =
already have to type out "<?php namespace foobar;=E2=80=9D at the start =
of each file, Perl programmers need "#!/usr/bin/perl=E2=80=9D and =E2=80=9C=
use warnings; use strict=E2=80=9D, JS programmers need =E2=80=9C(function =
() { =E2=80=98use strict=E2=80=99; }());=E2=80=9D etc. Also, IDEs would =
help.

> > Strict type hinting is not suitable for PHP by definition (as a =
weakly
> > typed language), however, I see, it may be useful in some cases.
> > I would prefer to have "weak" types at first, then think about =
introducing
> > ability to switch to "strict" type hinting in context of use-cases.
>=20
> That'd be possible, but I fear that we'd just end up with weak typing =
only and no strict solution. Regardless of its merits, a large portion =
of the community is in favour of a strictly-typed solution. There are =
also a lot of people who are in favour of weak typing. So, this RFC =
tries to make a compromise.
>=20
> I see, but I afraid that compromise is worse than one or the other.

I=E2=80=99m actually convinced that this compromise is in some ways =
better than one or the other.

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).

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 =
not a string for $message:

    $foo =3D new Response;
    $foo->setBody(67);

Absurd example, but this sort of thing does happen in real world code, =
often 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 =
now 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 =
difficult.

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.

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.

This way, we can have stricter types without sacrificing compatibility =
or complicating migration.

Thanks.
--
Andrea Faulds
http://ajf.me/