Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:74112
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain fb.com designates 67.231.153.30 as permitted sender)
To: Levi Morrison <morrison.levi@gmail.com>
CC: internals <internals@lists.php.net>
Thread-Topic: [PHP-DEV] [RFC] Return Type Declarations pre-vote follow-up
Thread-Index: AQHPa5iwbRN8uH8IdkWOuZ8Vefj2F5s5InuAgAAU3YCAAAMQgIAAAZ+AgAAFEgA=
Date: Fri, 9 May 2014 21:56:04 +0000
Message-ID: <C4435E53-F8DB-4823-8C81-E3DDE9169D91@fb.com>
References: <CAFMT4Nrie2zAtVxcxg_xsDWs7EAa5fxk+d8aBH1=sZ=s_KFY2g@mail.gmail.com>
 <90B71511-4FB4-4916-9AC0-E3DD0D328C37@fb.com>
 <536D46C5.7040302@sugarcrm.com>
 <FCC3EA09-D690-4260-91DD-C361CF839FBB@fb.com>
 <CAFMT4NpPeJ_Nak_oqey6SbE8=5003ChE8zcv2xdh8QVNJfhZYg@mail.gmail.com>
In-Reply-To: <CAFMT4NpPeJ_Nak_oqey6SbE8=5003ChE8zcv2xdh8QVNJfhZYg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_C4435E53F8DB48238C81E3DDE9169D91fbcom_"
MIME-Version: 1.0
Subject: Re: [PHP-DEV] [RFC] Return Type Declarations pre-vote follow-up
From: jwatzman@fb.com (Josh Watzman)

--_000_C4435E53F8DB48238C81E3DDE9169D91fbcom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

On May 9, 2014, at 2:37 PM, Levi Morrison <morrison.levi@gmail.com<mailto:m=
orrison.levi@gmail.com>>
 wrote:

On Fri, May 9, 2014 at 3:32 PM, Josh Watzman <jwatzman@fb.com<mailto:jwatzm=
an@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 an=
notation 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 mean=
s that you don't have to convert your entire hierarchy all at once -- gradu=
al 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 b=
reak the return type? It's much harder to remove this behavior than it is t=
o add it in later.

Hack has "strict mode" (http://docs.hhvm.com/manual/en/hack.modes.strict.ph=
p) 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 leve=
l of safety you get from the stricter enforcement doesn't matter if the vas=
t 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 propo=
sal 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 stan=
ds is both a good step for PHP in and of itself, as well as a good step clo=
ser to Hack.

Josh Watzman


--_000_C4435E53F8DB48238C81E3DDE9169D91fbcom_--