On Mon, Feb 2, 2015 at 7:00 PM, Andrea Faulds <a...@ajf.me> wrote:
> 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.
>
Eh ... sorry for not mentioning that in the same mail, but I've never
suggested a strict-only approach.
Cheers,
Andrey.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
