Re: [RFC] Scalar Type Hints v0.2

On Mon, Feb 2, 2015 at 7:00 PM, Andrea Faulds <ajf@ajf.me> wrote: > Hi Andrey, > >> On 2 Feb 2015, at 16:57, Andrey Andreev <narf@devilix.net> wrote: >> >> On Mon, Feb 2, 2015 at 6:52 PM, Andrea Faulds <ajf@ajf.me> wrote: >>> Hi Andrey, >>> >>>> On 2 Feb 2015, at 16:48, Andrey Andreev <narf@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.