Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:74109
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <90B71511-4FB4-4916-9AC0-E3DD0D328C37@fb.com>
References: <CAFMT4Nrie2zAtVxcxg_xsDWs7EAa5fxk+d8aBH1=sZ=s_KFY2g@mail.gmail.com>
	<90B71511-4FB4-4916-9AC0-E3DD0D328C37@fb.com>
Date: Fri, 9 May 2014 15:27:45 -0600
Message-ID: <CAFMT4NrWkbM+3BpD+pX94x8vwijZrN4dgEJU2xUTwNjNm0R6Uw@mail.gmail.com>
To: Josh Watzman <jwatzman@fb.com>
Cc: internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e0160c34ec1f69b04f8fe44ed
Subject: Re: [PHP-DEV] [RFC] Return Type Declarations pre-vote follow-up
From: morrison.levi@gmail.com (Levi Morrison)

--089e0160c34ec1f69b04f8fe44ed
Content-Type: text/plain; charset=UTF-8

Minor issues first:

First minor issue: you have a return type "self". This is an LSB type,
> effectively the type of "new static". Levi, I remember discussing this with
> you in IRC, but not the result of that discussion. What is the reason for
> "self"? The Hack type system calls it "this", which I admit is a little
> confusing since it is the type of more things than just the literal
> variable "$this" ("new static" for example is also of type "this"). But the
> type "static" is much more consistent with the existing LSB language, i.e.,
> "new static". So is there any reason to call it "self" over "static" or
> "this"?
>

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.


> Second minor issue: your reflection implementation is slightly different
> from HHVM's. I'm told we call the method "getReturnTypeText", which returns
> the hint text, or false if none exists. I don't know how strongly we feel
> about this, but at the very least, I wanted to make sure you were aware
> that you were definitely diverging from the existing implementation here,
> and that it was done intentionally. (Also, I don't think you have any test
> coverage of this feature?)


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 Reflection
anyway.

--089e0160c34ec1f69b04f8fe44ed--