The "pipe operator" |>
allows you to chain multiple function calls in a more convenient way.
$result = "Hello World" |> 'htmlentities' |> 'str_split' |> fn($x) => array_map('strtoupper', $x) |> fn($x) => array_filter($x, fn($v) => $v != 'O');
This RFC was already declined, but we're sharing it here as another test RFC, and because it'd be interesting to learn people's opinion about it.
I've been waiting for pipe operators in a very long time.
It is awesome.
finally
It will introduce new complexities in debugging and error handling and also existing library implementations (e.g., Laravel's pipeline) already offer similar functionality without needing language changes. Instead of achieving the same result with simple code why do we attempt to pollute the current syntax.
$value = 'Hello world';
array_map(static function($fn) use (&$value){
if(is_callable($fn)){
$value = $fn($value);
}
}, [
'htmlentities',
'str_split',
fn($x) => array_map('strtoupper', $x),
fn($x) => array_filter($x, fn($v) => $v != 'O')
]);
var_dump($value);
Much cleaner than multiple variables or lots of indentation.
I like the concept but not the operator. As one of the other commenters said, it would be better if all the scaler
So much energy invested into some messy code, where not even 'htmlentities' can be found by IDE, as it's a string. Why is the following edge-case (!) not convenient enough?
$result = "Hello World"; $result = htmlentities($result); $result = str_split($result); $result = array_map('strtoupper', $result); $result = array_filter($result, fn($v) => $v != 'O');
or
$result = strtoupper(htmlentities("Hello World")); $result = array_filter(str_split($result), fn($v) => $v != 'O');
str_split
, or specifying flags for htmlentities
in the example) is not possible (or either will be really difficult to read, or will require to wrap it in arrow functions).In classic PHP this is totally fine to read:
$input = 'Hello World'; $encoded = htmlentities($input, double_encode: false); $list = str_split($encoded); $uppercased = array_map(strtoupper(...), $list); $result = array_filter($uppercased, fn($v) => $v !== '0'));
We should accept any RFC increasing the capacity of PHP to design things elegantly. Which is done by this suggestion.
I voted "Yes".
PHP misses linear function composition... until now.
I find this syntax pretty messy, to be frank. Maybe it's a good idea (since it is available in "modern languages"), but not something I would use much or even recommend using...
Imagine, having chainable functions like Laravel collections inside php
$result = collect("Hello World") ->map(fn($x) => htmlentities($x)) ->map(fn($x) => str_split($x)) ->map(fn($x) => array_map('strtoupper', $x)) ->map(fn($x) => array_filter($x, fn($v) => $v != 'O')); $result = "Hello World" |> 'htmlentities' |> 'str_split' |> fn($x) => array_map('strtoupper', $x) |> fn($x) => array_filter($x, fn($v) => $v != 'O');
That would be so useful. Not to mention about pipeline pattern, which can be implemented with this, so easy. I do like First-class callable syntax.
It would make chaining arguments easier to read, but that it. No good control over the exact output and it is really different from the PHP programming way. For me its more a maybe.
i think php should have more build in support for functional programming concepts so pipe operator looks like a good idea to me. i do agree that the syntax maybe needs some work.
Interface Default Methods improves backwards compatibility when changing interfaces, but also add a way to have multi-inheritance in PHP.
This RFC proposes a way to have multi-line short closures — closures that don't need explicit use
statements, but can still have multiple lines and a return statement.