Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81625
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.220.178 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <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>
	<5175DE01-ADC9-4A0B-8343-820C53B30054@ajf.me>
Date: Mon, 2 Feb 2015 22:22:41 +0400
Message-ID: <CA+9eiLv+FCqiEmaM-NjGtMnpxyYb+x7zgrR5pneJmZowauDYBA@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b86d9902f6d54050e1f0ae7
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2
From: dmitry@zend.com (Dmitry Stogov)

--047d7b86d9902f6d54050e1f0ae7
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

So, one of the advantages of strict type hinting is the ability to catch
potential errors.
For example when we pass 67 to setBody(string $message).

Thanks. Dmitry.


On Mon, Feb 2, 2015 at 7:30 PM, Andrea Faulds <ajf@ajf.me> wrote:

> Hi Dmitry,
>
> > On 2 Feb 2015, at 09:24, Dmitry Stogov <dmitry@zend.com> wrote:
> >
> > > Will we able to call the same function using weak
> > > type hinting from on file and with strict from the other?
> >
> > Yes, for the parameter type hints anyway. That means that strict and
> weak code is interoperable without enforcing a model on each other.
> >
> > 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, easi=
er
> migration of existing codebases, and most importantly, allows people to
> choose one mode or another without affecting other users that have to cal=
l
> 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=99=
s 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 m=
ixing 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 f=
ile, Perl
> programmers need "#!/usr/bin/perl=E2=80=9D and =E2=80=9Cuse 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 weakl=
y
> > > 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.
> >
> > 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 mak=
e
> a compromise.
> >
> > 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 bette=
r 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 wa=
s
> 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 no=
t 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 c=
ode from
> earlier that took advantage of PHP=E2=80=99s weak typing would now produc=
e 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 dif=
ficult.
>
> 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 err=
or
> 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/
>
>
>
>
>

--047d7b86d9902f6d54050e1f0ae7--