Re: [RFC] Return Type Declarations pre-vote follow-up

On May 9, 2014, at 2:37 PM, Levi Morrison <morrison.levi@gmail.com<mailto:morrison.levi@gmail.com>> wrote: On Fri, May 9, 2014 at 3:32 PM, Josh Watzman <jwatzman@fb.com<mailto:jwatzman@fb.com>> wrote: > I'm not sure it is a good idea. This means having this code: > class FooGetter { > function getFoo(): Foo { return new Foo(); } > } > > I can extend it as: > class TwoFaceFooGetter extends FooGetter { > function getFoo() { return rand()%2?new Bar():new Foo(); } > } > > and every function getting FooGetter and expecting getFoo() to return > Foo is now broken since instead it could just get Bar(). Since the type > return specification is meant, as far as I understand, exactly to avoid > cases like that, I don't see it as a good idea. Our view is that this code was *already* wrong. The type annotations don't make it more or less wrong. What they do let you do is enforce, once the annotation is in place, that it's correct moving forward for the places that are annotated. (And if you want to go fix up and annotate TwoFaceFooGetter, go do that! Or if you don't right now, don't!) Doing it this way also means that you don't have to convert your entire hierarchy all at once -- gradual conversion of existing code was an important feature when we were adding the Hack type system onto PHP. The behavior you are proposing is good for migration and adoption, but what then? What about the years afterwards where you now have this ability to break the return type? It's much harder to remove this behavior than it is to add it in later. Hack has "strict mode" (http://docs.hhvm.com/manual/en/hack.modes.strict.php) which simply doesn't let you omit an annotation anywhere, which you can use to "lock in" a fully annotated file. We were also just discussing that it might make sense to enforce strict mode for an entire hierarchy, though we don't have anything like this right now. New Hack code can be all strict and thus all type-safe. I'm not sure if you'd want to actually add some notion of per-file "modes" like this, but it's been important to our type system adoption. Having some way to gradually type things was critical for us. The slightly higher level of safety you get from the stricter enforcement doesn't matter if the vast majority of folks (existing code) can't use it ;) But as you say, it's a lot easier to loosen in the future; since this proposal is stricter than HHVM, I've said my piece and will get out of your way ;) I wish you'd change your mind here, but I still think the RFC as it stands is both a good step for PHP in and of itself, as well as a good step closer to Hack. Josh Watzman