Re: [RFC] Scalar Type Hints v0.2

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. -- Andrea Faulds http://ajf.me/