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
Thread (15 messages)