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 <a...@ajf.me> wrote:
> Hi Dmitry,
>
> > On 2 Feb 2015, at 09:24, Dmitry Stogov <dmi...@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’s 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=1) everywhere that
> would turn PHP into Java.
>
> Well, not quite Java, but yes. Typing it out is annoying. But it’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’s 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;” at the start of each file, Perl
> programmers need "#!/usr/bin/perl” and “use warnings; use strict”, JS
> programmers need “(function () { ‘use strict’; }());” 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.
> >
> > 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.
> >
> > I see, but I afraid that compromise is worse than one or the other.
>
> I’m 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’t
> suddenly break calling code that didn’t 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’s perfectly fine to pass something that’s not a string for
> $message:
>
> $foo = new Response;
> $foo->setBody(67);
>
> Absurd example, but this sort of thing does happen in real world code,
> often accidentally.
>
> Now, let’s say we add a string type hint in a new version of the library:
>
> interface Response {
> public function setBody(string $message);
> }
>
> If PHP’s type hints were always strict, then our existing PHP 5 code from
> earlier that took advantage of PHP’s 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’t good - it makes migration of the existing codebase difficult.
>
> Weak typing solves this problem because it allows conversions. However,
> it’s 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’t break initially. But once you’ve 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/
>
>
>
>
>
