Methods which auto-return the class instance

Le 23 déc. 2022 à 01:08, joke2k joke2k@gmail.com a écrit :

Hi folks,

What do you think about having a method which returns the class instance
$this by default only IF its return type is set as self?

It is very common for fluent class methods to have a verbose return $this; ending in their body.
But If you have declared self as return type into a non-static class
method you have only two options to return:

• the $this object
• another instance of the same class or subclass

... in order to avoid a return type error.

It is still two options, and it is not clear in general which one to pick. You could also say that, if you have object as return type, there are two options to avoid a return type error: either return the $this object, or return another object.

My proposal is to set the instruction return $this; as optional for
non-static class methods with self declared as return type.

I’d rather have a syntax saying explicitly that you want to return $this, rather than letting the interpreter guess what you meant. The obvious one is:

public function hit(): $this { $this->counter++; }

Here, there is only one possible return value, and therefore the return instruction might be reasonably omitted.

The real question is: Is it worth to add special cases for some specific return values?

—Claude

Hi folks,

What do you think about having a method which returns the class instance
$this by default only IF its return type is set as self?

It is very common for fluent class methods to have a verbose return $this; ending in their body.
But If you have declared self as return type into a non-static class
method you have only two options to return:

• the $this object
• another instance of the same class or subclass

... in order to avoid a return type error.

My proposal is to set the instruction return $this; as optional for
non-static class methods with self declared as return type.

Example:

class Counter {

public function __construct(private int $counter = 0) {}

public function hit(): self { $this->counter++; }
public function print(): self { echo $this->counter; }

public function split(): self { return new self($this->counter); }

}

$main = (new Counter)->hit()->hit()->hit()->print()
// 3
$sub = $main->split()->hit()->print()
// 4

Thank you for reading my proposal,
please let me know if you like it or if there are any issues with this.

Regards,

Daniele

As someone who used Scala for a number of years, I’d be very much
against this idea. Scala automatically returns the last line of any
function and we found it fairly difficult to maintain once the project
got fairly large and ended up switching to explicit returns. Mostly we
found it too easy to return the wrong thing.

In all fairness, I guess you technically don’t have to use it if you
don’t want to (you can use explicit returns), but IMHO, using this
would greatly affect readability. Every function you read that doesn’t
have a return, you’d have to check if the return type is self/static
and verify it is void.

--
Robert Landers
Software Engineer
Utrecht NL

Hi Daniele

Hi folks,

What do you think about having a method which returns the class instance
$this by default only IF its return type is set as self?

It is very common for fluent class methods to have a verbose return $this; ending in their body.

Instead of adding special syntax to make writing fluent accessors
easier, I wonder if something akin to Dart's cascade operator would be
a better approach.

https://dart.dev/guides/language/language-tour#cascade-notation

$foo
..setBar('bar')
..setBaz('baz');

The syntax is just copied from Dart, there's probably a better fit for
PHP. .. would invoke a method call but discard the return value,
evaluating to the lhs of the method call instead.

With an operator solution one can use fluent method calls on APIs that
aren't specifically designed for it when desired, accessors can become
leaner as return $this is no longer necessary, and it becomes obvious
at call-site that the chained methods are called on the same object.

I'm not sure about syntax or the fact that Dart allows property
assignments in combination with .. as that makes the syntax ambiguous
(or whitespace sensitive), but that wouldn't be necessary for what
you're proposing.

Example of the ambiguity:

$foo
..bar = $bar
..baz()
// Could be parsed as
$foo..(bar = $bar)..baz()
$foo..bar = ($bar..baz())

An alternative might be a C# style syntax which would make property
assignments unambiguous.

$foo {
setBar('bar'),
baz = 'baz',
}

But this is also longer and less readable (to me at least).

Anyway, just my unrefined thoughts. I would not support implicit
return $this for self or static. At the very least, the return type
should be $this (which is essentially a sub-type of static) but that
too doesn't seem like an elegant solution to me.

Ilija