Everything

php

Home » Project » Newsgroups » php.internals » [RFC] $this return type »

[RFC] $this return type

php.internals

Nikita Popov

4 years ago

Hi internals,

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 see
the practical usefulness, so I think it's worth discussing this.

Regards,
Nikita

Michał Brzuchalski

4 years ago

Hi Nikita,

wt., 7 wrz 2021 o 12:29 Nikita Popov <nikita.ppv@gmail.com> napisał(a):

> Hi internals,
>
> 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 see
> the practical usefulness, so I think it's worth discussing this.

If the aim of $this return type is to force and check the return $this why
would we still need/require return statement to be obligatory?
Does that make sense to assume at the end of function flow the return
$this; statement to be present by default if the return type is not an
union etc.?

Cheers,

--
Michał Marcin Brzuchalski

Andreas Heigl

4 years ago

Hey Nikita

On 07.09.21 12:28, Nikita Popov wrote:

> Hi internals,
>
> 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 see
> the practical usefulness, so I think it's worth discussing this.
>
> Regards,
> Nikita

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*  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?

Cheers

Andreas

--
,,,
(o o)
+---------------------------------------------------------ooO-(_)-Ooo-+
| Andreas Heigl                                                       |
| mailto:andreas@heigl.org                  N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org                                           |
+---------------------------------------------------------------------+
| https://hei.gl/appointmentwithandreas                               |
+---------------------------------------------------------------------+

Christoph Becker

4 years ago

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 see
>> 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*  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

Sebastian Bergmann

4 years ago

Am 07.09.2021 um 12:28 schrieb Nikita Popov:

> 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 see
> the practical usefulness, so I think it's worth discussing this.

I am not conviced that there is enough value in this to introduce syntax
for it, but if at all, then please not "$this" as the name for a type.

Off the top of my head, I think that "same" could make sense.

Flávio Heleno

4 years ago

On Tue, Sep 7, 2021 at 10:27 AM Sebastian Bergmann <sebastian@php.net>
wrote:

> Am 07.09.2021 um 12:28 schrieb Nikita Popov:
> > 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 see
> > the practical usefulness, so I think it's worth discussing this.
>
> I am not conviced that there is enough value in this to introduce syntax
> for it, but if at all, then please not "$this" as the name for a type.
>
> Off the top of my head, I think that "same" could make sense.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Hi all,

I'm sorry if I'm being naive, or simply put dumb, but the main difference
that we're trying
to achieve with having "$this" (or variations of it) as a valid return type
as opposed to simply
using "self" is to ensure that the underlying code is actually doing a
"return $this" rather
than returning any other valid "self" instance (such as "return new
self();")?

--
Atenciosamente,

Flávio Heleno

Mike Schinkel

4 years ago

> On Sep 9, 2021, at 10:26 AM, Flávio Heleno <flaviohbatista@gmail.com> wrote:
>
> On Tue, Sep 7, 2021 at 10:27 AM Sebastian Bergmann <sebastian@php.net>
> wrote:
>
>> Am 07.09.2021 um 12:28 schrieb Nikita Popov:
>>> 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 see
>>> the practical usefulness, so I think it's worth discussing this.
>>
>> I am not conviced that there is enough value in this to introduce syntax
>> for it, but if at all, then please not "$this" as the name for a type.
>>
>> Off the top of my head, I think that "same" could make sense.
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: https://www.php.net/unsub.php
>>
>>
> Hi all,
>
> I'm sorry if I'm being naive, or simply put dumb, but the main difference
> that we're trying
> to achieve with having "$this" (or variations of it) as a valid return type
> as opposed to simply
> using "self" is to ensure that the underlying code is actually doing a
> "return $this" rather
> than returning any other valid "self" instance (such as "return new
> self();")?

So a *mutable* fluent style vs. an *immutable* fluent style?

-Mike

Ben Ramsey

4 years ago

> On Sep 9, 2021, at 09:47, Mike Schinkel <mike@newclarity.net> wrote:
>
>> On Sep 9, 2021, at 10:26 AM, Flávio Heleno <flaviohbatista@gmail.com> wrote:
>>
>> On Tue, Sep 7, 2021 at 10:27 AM Sebastian Bergmann <sebastian@php.net>
>> wrote:
>>
>>> Am 07.09.2021 um 12:28 schrieb Nikita Popov:
>>>> 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 see
>>>> the practical usefulness, so I think it's worth discussing this.
>>>
>>> I am not conviced that there is enough value in this to introduce syntax
>>> for it, but if at all, then please not "$this" as the name for a type.
>>>
>>> Off the top of my head, I think that "same" could make sense.
>>>
>>> --
>>> PHP Internals - PHP Runtime Development Mailing List
>>> To unsubscribe, visit: https://www.php.net/unsub.php
>>>
>>>
>> Hi all,
>>
>> I'm sorry if I'm being naive, or simply put dumb, but the main difference
>> that we're trying
>> to achieve with having "$this" (or variations of it) as a valid return type
>> as opposed to simply
>> using "self" is to ensure that the underlying code is actually doing a
>> "return $this" rather
>> than returning any other valid "self" instance (such as "return new
>> self();")?
>
> So a *mutable* fluent style vs. an *immutable* fluent style?
>
> -Mike

For clarity, in comparing to `self` and `static`…


`self`
:   the return value must be an instance of the same class that sets
this type declaration


`static`
:   the return value must be an instance of the same class that calls
the method with this type declaration


`$this`
:   the return value must be the same instance as the instance that
calls the method with this type declaration


Cheers,
Ben

Nicolas Grekas

4 years ago

Hi Nikita

Hi internals,

>
> 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 see
> the practical usefulness, so I think it's worth discussing this.
>

Thank you so much for the RFC. I'm really looking forward to being able to
use $this as a return type.

> On a dataset of 2k composer packages, @return $this occurs 29k times,

while @return static is used 38k times

This is really good to know. It makes it pretty clear to me that being able
to declare $this as a return value would be valuable to many projects!

As far as my experience is concerned, I tried switching from the `@return
$this` annotation to `function (): static`, which is the closest
approximation currently supported by the engine, when I realized that this
would loosen the semantics of the corresponding interfaces and kinda force
ppl to deal with the return value while this doesn't make sense in
fluent-style APIs. I therefore kept the annotation in place and I'm now
looking forward to being able to write this declaration using native syntax
- with the added benefit of having it enforced by the engine.

About the syntax, I think the one proposed in the RFC is crystal clear.
I've been used to seeing the "$" symbol when reading `@return $this`, and
this just makes sense, past the first surprise. I also think that using
"this" (without the dollar) could too easily be confused with something
that means our "static" (esp. considering that TypeScript uses "this" in
place of our "static".)

I'm reading in responses that $this is not a type, but I fail to understand
how that makes it an argument against the RFC. Neither false is a type, and
null is both a type and a value. Yet we have them because they provide
clear added value. Having $this could benefit 29k times the top 2k
packages. It doesn't look like a niche use case!

As you might have understood, I support the RFC and would vote for it as is
personally!

Nicolas