Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126329
Precedence: bulk
MIME-Version: 1.0
Date: Fri, 07 Feb 2025 14:32:14 +0100
To: internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Pipe Operator (again)
In-Reply-To: <de8140ab-0941-45cd-ba20-4aece2f69aea@app.fastmail.com>
References: <de8140ab-0941-45cd-ba20-4aece2f69aea@app.fastmail.com>
Message-ID: <5a584219f120385e7e30f6d0a46cc108@bastelstu.be>
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

Hi

Am 2025-02-07 05:57, schrieb Larry Garfield:
> It is now back with a better implementation (many thanks to Ilija for 
> his help and guidance in that), and it's nowhere close to freeze, so 
> here we go again:
> 
> https://wiki.php.net/rfc/pipe-operator-v3

There's some editorial issues:

1. Status: Draft needs to be updated.
2. The RFC needs to be added to the overview page.
3. List formatting issues in “Future Scope” and “Patches and Tests”.

Would also help having a closed voting widget in the “Proposed Voting 
Choices” section to be crystal clear on what is being voted on (see 
below the next quote).

---------

Regarding the contents:

4. “That is, the following two code fragments are also exactly 
equivalent:”.

I do not believe this is true (specifically referring to the “exactly” 
word in there), since the second code fragment does not have the short 
closures, which likely results in an observable behavioral difference 
when throwing Exceptions (in the stack trace) and also for debuggers. Or 
is the implementation able to elide the the extra closure? (Of course 
there's also the difference between the temporary variable existing, 
with would be observable for `get_defined_vars()` and possibly 
destructors / object lifetimes).

5. The “References” (as in reference variables) section would do well 
with an example of what doesn't work.

6. In the “Compose” section: The section always uses the word 
“callables”, but doesn't explain how it resolves the ambiguity of 
`[Foo::class, 'bar'] + [Bar::class, 'foo']`.

Should it read “Closures” instead of “callables”?

7. In the “Compose” section: It would be useful to explicitly spell out 
in which order the individual callables are called.

Will `(strrev(...) + ucfirst(...))("foo")` result in `ooF` or will it 
result in `Oof`?

8. In the “Compose” section: The RFC says that “ComposedClosure” is not 
quite equivalent, but it doesn't go into detail what is not quite 
equivalent.

Specifically: Is the result actually limited to a single argument? Using 
the `ooF` evaluation order, `(strlen(...) + str_replace(...))("o", "", 
"foo")` could reasonably result in `1`.

9. In the “Why in the engine?” section: The RFC makes a claim about 
performance.

Do you have any numbers?

> Of particular note, since the last RFC I have concluded that a compose 
> operator is a necessary complement to a pipe operator.

The RFC lists “Compose” as part of the “Proposal” section, but also the 
“Future Scope”. Should the part in “Proposal” be removed?

> However, it's also going to be notably more work, and the two operators 
> don't actually interact at all at the code level, so since people keep 
> saying "Small RFCs!", here's a small RFC. :-)

I like this.

Best regards
Tim Düsterhus