Hi Andrey,
> On 2 Feb 2015, at 16:57, Andrey Andreev <[email protected]> wrote:
>
> On Mon, Feb 2, 2015 at 6:52 PM, Andrea Faulds <[email protected]> wrote:
>> Hi Andrey,
>>
>>> On 2 Feb 2015, at 16:48, Andrey Andreev <[email protected]> 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 ability 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=1 ... nobody needs that and
>>> it doesn't have to be done.
>>
>> I wasn’t talking about internal functions… I’m talking about userland code in the
>> hypothetical case that we added strict-only hints.
>>
>> I don’t see where you’ve 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’ll just quote my previous message:
> 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.
Basically, strict-only types complicates their addition to existing codebases, including libraries.
What this RFC proposes is similar to Hack’s gradual typing, in a sense, in that it allows you to
gradually add types to your codebase without breaking things.
--
Andrea Faulds
http://ajf.me/