Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115993
To: Andreas Heigl <andreas@heigl.org>, internals@lists.php.net
References: <CAF+90c9Qxuq=Q3eGq2pLHtvTP=z4pCTgtjwHOehTuOi4vZXvoA@mail.gmail.com>
 <d80ac7e4-db2d-db0b-72c4-7daf5fa12280@heigl.org>
Message-ID: <341d3b94-01ff-156c-fb80-0c036fb1b55a@gmx.de>
Date: Tue, 7 Sep 2021 15:24:02 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <d80ac7e4-db2d-db0b-72c4-7daf5fa12280@heigl.org>
Content-Type: text/plain; charset=utf-8
Content-Language: de-DE
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] $this return type
From: cmbecker69@gmx.de ("Christoph M. Becker")

On 07.09.2021 at 15:02, Andreas Heigl wrote:

> On 07.09.21 12:28, Nikita Popov wrote:
>
>> I'd like to pick up a loose thread from the future scope of the
>> https://wiki.php.net/rfc/static_return_type RFC, the $this return type
>> for
>> fluent APIs:
>>
>> https://wiki.php.net/rfc/this_return_type
>>
>> I have some reservations about this (which basically come down to
>> $this not
>> being a proper "type", so should it be in the type system?) but I can s=
ee
>> the practical usefulness, so I think it's worth discussing this.
>
> If we allow a $this (let's keep the actual naming out for the moment) as
> a returntype to clarify that it has to be the same instance that is
> returned, I would also either expect that the returntype 'self' does
> explicitly *not* allow the same instance to be returned. As that would
> be a huge BC break I would on the other hand also think that we should
> implement a returntype "!$this" to explicitly state that the contract
> here returns *not*=C2=A0 the current instance but a new one. That way a =
lot
> of immutable contracts could be made more clear.
>
> What'S your or others idea regarding that?

In my opinion, we should not muddy the waters here.  $this is not a type.

Instead we should consider to head for a more general solution, namely
suporting post-conditions, i.e. assertions which are part of the
function/method signature.  But that would certainly be the topic of
another RFC.

Christoph