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
