Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73826
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.171 as permitted sender)
MIME-Version: 1.0
Sender: julienpauli@gmail.com
In-Reply-To: <CAFMT4NqdEZv95tVe2SSOoa1FhUSDFbXi9Mw3q+SAdT-SPN62Sg@mail.gmail.com>
References: <CAFMT4NoUZ7==rmLtuohHrddNnurOe-quPL9q_=WbdNV+jo1kYA@mail.gmail.com>
 <CAMyk_AYNCTQDqycU=-DU8EOtZn-Sgm1uKStkOgvdP7aCn31kfw@mail.gmail.com>
 <CAFMT4NpMPCxvnPm+UAqLEKjmHLJ9t0zhwKAkVbZ=a9nv2ECaGA@mail.gmail.com>
 <1398437995.20097.110370617.51C52C36@webmail.messagingengine.com> <CAFMT4NqdEZv95tVe2SSOoa1FhUSDFbXi9Mw3q+SAdT-SPN62Sg@mail.gmail.com>
Date: Mon, 28 Apr 2014 11:23:51 +0200
Message-ID: <CAMUwpuRXuumh5_st8TTBn2ZBHfOsT2cf73=zcejQtBuK41=XWg@mail.gmail.com>
To: Levi Morrison <morrison.levi@gmail.com>
Cc: Will Fitch <willfitch@php.net>, Lazare Inepologlou <linepogl@gmail.com>, 
	internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC] Return Type Declarations
From: jpauli@php.net (Julien Pauli)

On Fri, Apr 25, 2014 at 11:10 PM, Levi Morrison <morrison.levi@gmail.com> wrote:
> On Fri, Apr 25, 2014 at 8:59 AM, Will Fitch <willfitch@php.net> wrote:
>
>> On Fri, Apr 25, 2014, at 07:52 AM, Levi Morrison wrote:
>> > On Fri, Apr 25, 2014 at 3:09 AM, Lazare Inepologlou
>> > <linepogl@gmail.com>wrote:
>> >
>> > > Hello,
>> > >
>> > > 2014-04-24 17:59 GMT+02:00 Levi Morrison <levim@php.net>:
>> > >
>> > > My dear Internals friends,
>> > >>
>> > >> I have spent the last month drafting an RFC that allows return types:
>> > >> https://wiki.php.net/rfc/returntypehinting
>> > >>
>> > >> Notable items:
>> > >>   -  Differences from past RFCs are summarized in the RFC:
>> > >> https://wiki.php.net/rfc/returntypehinting#differences_from_past_rfcs
>> > >>   - The patch includes basic opcache and reflection support. It also
>> has
>> > >> phpt tests.
>> > >>   - Informal performance tests indicate that the patch did not fubar
>> > >> performance; if desired a more detailed test can be conducted before
>> > >> voting.
>> > >>   - This RFC does not add, modify, or remove keywords at all; this
>> notably
>> > >> excludes type-hints for scalars. Supporting scalar type declarations
>> is
>> > >> outside the scope of this RFC; if you are interested in supporting
>> scalar
>> > >> type declarations please discuss it elsewhere.
>> > >>
>> > >> As a friendly reminder, everyone on this list is interested in
>> developing
>> > >> a
>> > >> better PHP and the definitions of 'better' vary from person to person.
>> > >> Please be civil and constructive while discussing this RFC. Thank you!
>> > >>
>> > >> Some thanks, regardless if the RFC is accepted:
>> > >>   - For providing a patch: Joe Watkins.
>> > >>   - For helping me iterate on RFC drafts: Bob Wienand, Nikita Popov
>> and
>> > >> Anthony Ferrara
>> > >>   - For previous RFCs on this topic: Felipe Pena and Will Fitch. I
>> gleaned
>> > >> valuable knowledge from your proposals and the discussion around them.
>> > >>
>> > >
>> > >
>> > > This is a nice and well thought proposal.
>> > >
>> > > I would like to suggest the addition of the "self" and "static" pseudo
>> > > types. Most IDEs support this through @return syntax:
>> > >
>> > > class Foo {
>> > >   /** @return static */
>> > >   public function SetBar( $bar ) {
>> > >      // ...
>> > >      return $this;
>> > >   }
>> > > }
>> > >
>> > > With the new syntax, the above could be transformed into this:
>> > >
>> > > class Foo {
>> > >   public function SetBar( $bar ) : static {
>> > >      // ...
>> > >      return $this;
>> > >   }
>> > > }
>> > >
>> >
>> > As the patch currently stands you can use the type-hint 'self'.
>>
>> How will this patch work with LSB?
>>
>
> Late static binding is not a feature I am very familiar with. After some
> investigation it appears that we curently don't support late static binding
> on parameters; this means that I will not support late static binding on
> returns either. I want to keep the impact as small as possible.

Yep, this RFC is light and that's why it's nice :-)
I'm all +1 with it.

Keep the impact low as well as adding a nice, more-and-more-expected
feature, which keeps BC.
What should we ask for next ? :-)

You have my support.

Julien