Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108030
MIME-Version: 1.0
References: <CAF+90c-vPOmHzjoDFNi3m+iTgfz6dJep1DAHuCFcQDctjeEJMg@mail.gmail.com>
In-Reply-To: <CAF+90c-vPOmHzjoDFNi3m+iTgfz6dJep1DAHuCFcQDctjeEJMg@mail.gmail.com>
Date: Wed, 8 Jan 2020 11:57:31 +0000
Message-ID: <CALKiJKoCSxvi-L01ouxXhsDT8Msy0or1bZtG9mwUzCHVOcGSJQ@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000009c08f7059b9f99d9"
Subject: Re: [PHP-DEV] [RFC] Static return type
From: rowan.collins@gmail.com (Rowan Tommins)

--0000000000009c08f7059b9f99d9
Content-Type: text/plain; charset="UTF-8"

On Wed, 8 Jan 2020 at 11:42, Nikita Popov <nikita.ppv@gmail.com> wrote:

> I would like to propose the following RFC, which allows using "static" as a
> return type:
>
> https://wiki.php.net/rfc/static_return_type
>
> While I'm personally not a fan of late static binding, we do support it and
> people do use it quite heavily, so I think we should also support it in
> return types.
>


A big +1 from me; I'd probably have assumed it would work and be
disappointed when it didn't.

I can see why late static binding isn't to everyone's taste as a concept,
but it is very useful to emulate other features like named constructors, as
you show in the RFC.

The fluent interface example is interesting, because it doesn't actually
involve late static binding at all, we just need some way to say "what
comes out is the same type as what goes in".

Regards,
-- 
Rowan Tommins
[IMSoP]

--0000000000009c08f7059b9f99d9--