Hi Andrey,
> On 2 Feb 2015, at 16:57, Andrey Andreev <n...@devilix.net> wrote:
>
> On Mon, Feb 2, 2015 at 6:52 PM, Andrea Faulds <a...@ajf.me> wrote:
>> Hi Andrey,
>>
>>> On 2 Feb 2015, at 16:48, Andrey Andreev <n...@devilix.net> 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/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
