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/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
