Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:74110
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain fb.com designates 67.231.145.42 as permitted sender)
To: Stas Malyshev <smalyshev@sugarcrm.com>, Levi Morrison <levim@php.net>
CC: internals <internals@lists.php.net>
Thread-Topic: [PHP-DEV] [RFC] Return Type Declarations pre-vote follow-up
Thread-Index: AQHPa5iwbRN8uH8IdkWOuZ8Vefj2F5s5InuAgAAU3YCAAAMQgA==
Date: Fri, 9 May 2014 21:32:07 +0000
Message-ID: <FCC3EA09-D690-4260-91DD-C361CF839FBB@fb.com>
References: <CAFMT4Nrie2zAtVxcxg_xsDWs7EAa5fxk+d8aBH1=sZ=s_KFY2g@mail.gmail.com>
 <90B71511-4FB4-4916-9AC0-E3DD0D328C37@fb.com> <536D46C5.7040302@sugarcrm.com>
In-Reply-To: <536D46C5.7040302@sugarcrm.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-ID: <851825B04892224784DF22CC04CFADBF@fb.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [PHP-DEV] [RFC] Return Type Declarations pre-vote follow-up
From: jwatzman@fb.com (Josh Watzman)

> I'm not sure it is a good idea. This means having this code:
> class FooGetter {
>  function getFoo(): Foo { return new Foo(); }
> }
>=20
> I can extend it as:
> class TwoFaceFooGetter extends FooGetter {
>  function getFoo() { return rand()%2?new Bar():new Foo(); }
> }
>=20
> 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.

I understand, and this is the same argument LeviM has been making. (We just=
 discussed on IRC in #hhvm extensively.)

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 type 'self' is not late bound, unlike 'static' and exists in the lang=
uage elsewhere; I am not introducing a new keyword 'self' in this RFC.

We discussed this on IRC and came to consensus that "self" is just fine, th=
ough not necessarily terribly useful if you think further than just enforci=
ng the return type, to how that information might be propagated and used at=
 the callsite -- for example by the Hack static typechecker, or even by a h=
uman. The type "static" tends to be what you want. But this isn't a huge de=
al -- "self" as proposed isn't *wrong*.

> All we did was copy the existing structure in Parameter type hints; this =
was done for consistency. Is there any particular reason Hack/HHVM chose to=
 do something entirely different for return types in regards to reflection?=
 I don't particularly like the way type information is handled in Reflectio=
n anyway.

I don't know much about this or feel strongly one way or the other, just pl=
aying messenger.

Josh Watzman