Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:74111
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.173 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: Fri, 9 May 2014 15:37:55 -0600
Message-ID: <CAFMT4NpPeJ_Nak_oqey6SbE8=5003ChE8zcv2xdh8QVNJfhZYg@mail.gmail.com>
To: Josh Watzman <jwatzman@fb.com>
Cc: Stas Malyshev <smalyshev@sugarcrm.com>, internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e0158ab961e443304f8fe696e
Subject: Re: [PHP-DEV] [RFC] Return Type Declarations pre-vote follow-up
From: morrison.levi@gmail.com (Levi Morrison)

--089e0158ab961e443304f8fe696e
Content-Type: text/plain; charset=UTF-8

On Fri, May 9, 2014 at 3:32 PM, Josh Watzman <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.

--089e0158ab961e443304f8fe696e--