Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:100007
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.51 as permitted sender)
MIME-Version: 1.0
Date: Sat, 22 Jul 2017 12:37:03 +0100
Message-ID: <CALtMV+Pcx2XEcdAJfjfezJQv0qLQMm1gd34D1NewkZgED6gRzw@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="001a11476f9c98ecad0554e66630"
Subject: Pass-through object operator
From: aidantwoods@gmail.com (Aidan Woods)

--001a11476f9c98ecad0554e66630
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello Internals!

I'd like to gauge a reaction on a potential RFC proposal.

As per the RFC howto, I shall state that this would be a "concept" as I
don't have anyone lined up that would implement the feature, and I'm not a
C dev myself. (Though if no one volunteers I may take this as a learning
opportunity ;-) ).

The proposed feature is regarding method chaining.

There appear to be two design patterns that use it:

1. Where you deliberately act on very different objects returned in a
"flow" like way, e.g.
   ```
   $boo =3D $App->getConfig()->getId('foobar')->getValue();
   ```
2. For configuration, saving typing the original object multiple times
   ```
   $FooBar
       ->loadConfig($Config)
       ->loadExtensions($Extensions)
       ->run()
   ;
   ```

For the former, it relies on you knowing what is returned, and makes a nice
way of using what was returned easily.

For the latter, the actual method itself returning the instance seems a bit
useless as actual information (unless dealing with immutable objects =E2=80=
=93
where it in-fact returns a *new* instance. But that's really just the
former case =E2=80=93 since the method was designed with returning somethin=
g in
mind anyway).

So I wonder whether for the latter case, it would almost be better to
implement that kind of method chaining as a language feature (instead of
(ab)using a return statement that doesn't have anything to do with the
method's role).

So I would propose a new operator, perhaps `&>` is decent notation =E2=80=
=93 but
that could be discussed further if we like the concept. Assuming it's `&>`
in the following though:

`&>` would work almost exactly like `->`, except that instead of evaluating
to the value returned by the method call, it would evaluate to the object
on the LHS. A kind of "pass-through" operator if you will.

So instead of the author of the object adding support for this
configuration method chaining style (they might not be able to for all
methods), you could instead use the `&>` operator to do it =E2=80=93 this a=
ll in a
way that is clear to the reader too. You could even use it on methods that
*do* return things (if you don't care about what's returned).

I.e. write this (knowing that it would work: because language feature).

```
$Foo
  &>bar()
  &>baz()
;
```

Which would have the written meaning: "call `$Foo`'s `bar()` *and* `baz()`
methods".

Other examples:

You want to instantiate an object *and* call a couple of methods, and also
get a reference to that object.

Before:
```
($Foo =3D new Foo)->bar();
$Foo->baz();
```

With the "pass-through" operator:

```
$Foo =3D (new Foo)&>bar()&>baz();
```

Thanks for reading if you got this far, I shall look forward to hearing
feedback.

Kind regards,
Aidan

--001a11476f9c98ecad0554e66630--