Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:74114
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.219.49 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <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> <FCC3EA09-D690-4260-91DD-C361CF839FBB@fb.com>
Date: Sat, 10 May 2014 11:06:52 +0200
Message-ID: <CAMyk_AbanA8GH31f8PQ4xXUDUCfyvuR6sv1aUahWu6fM4wSugw@mail.gmail.com>
To: Josh Watzman <jwatzman@fb.com>
Cc: Stas Malyshev <smalyshev@sugarcrm.com>, Levi Morrison <levim@php.net>, 
	internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e015372c62dd61f04f9080a06
Subject: Re: [PHP-DEV] [RFC] Return Type Declarations pre-vote follow-up
From: linepogl@gmail.com (Lazare Inepologlou)

--089e015372c62dd61f04f9080a06
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hello,

2014-05-09 23:32 GMT+02:00 Josh Watzman <jwatzman@fb.com>:

> > 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.
>
> 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
> 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 featu=
re
> when we were adding the Hack type system onto PHP.
>
> > The type 'self' is not late bound, unlike 'static' and exists in the
> language 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,
> though not necessarily terribly useful if you think further than just
> enforcing the return type, to how that information might be propagated an=
d
> used at the callsite -- for example by the Hack static typechecker, or ev=
en
> by a human. The type "static" tends to be what you want. But this isn't a
> huge deal -- "self" as proposed isn't *wrong*.
>
>
As far as I understand, the keyword "self" was just inherited from argument
type hinting. The keyword "static" is not used there, so it was not carried
over.

Maybe "static" should be introduced to both cases, but in a separate RFC.



Lazare INEPOLOGLOU
Ing=C3=A9nieur Logiciel

--089e015372c62dd61f04f9080a06--