The Pipe Operator

Read the RFC Externals
90
262 yes
126 no

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.

Click the bar to cast your vote!
68%
32%
1

Used pipe operators in Elixir lang and loved it. This will help make code more readable.

Share:
robindrost avatar
robindrost
voted yes
1

I like the proposition, but I would use some special "variable" ($$) for piped value (see v1 proposition: https://wiki.php.net/rfc/pipe-operator) so you don't have to use closures inside pipe to place value

$name = 'my_user_name'
	|> str_replace('_', ' ', $$)
	|> strtolower($$)
	|> ucwords($$)
	|> trim($$);

I don't like mapping function names as strings too

Share:
yoshi129 avatar
yoshi129
voted yes
1

That's awful, we see strings not function calls.

Share:
davg avatar
davg
voted no
1

Voting Yes - but only if the RFC were updated to use First-class callable syntax only instead of strings for the functions. Would vote no looking at it based on the RFC alone, but looking at Roman's example I really wouldn't mind that. But I would 100% vote No if it were the original examples from the RFC text.

That in mind, would this RFC vote site benefit from a method to capture these types of votes? I.e. one where the vote would be No as proposed in the RFC currently, but could be a Yes with minor changes to update for other already accepted RFC.

Share:
mallardduck avatar
mallardduck
voted yes
1

really useful for chained method calls that already are crowded because of PHPs -> operator

Share:
ricardo avatar
ricardo
voted yes
1

I'm a fan of the method chaining pattern. This would be a nice way to have similar behaviour without having to create a class.

Share:
timvandijck avatar
timvandijck
voted yes
1

RFC shouldn't be a place to propose new syntax because laravel is messy

Share:
thomas-kl1 avatar
thomas-kl1
voted no
1

I think this would clean up a lot of messy code, much better than nesting functions

Share:
colinhall17 avatar
colinhall17
voted yes
1

I like what the pipe operator provides, but I don't like the string-based syntax that's proposed. It feels weird to me that we're calling functions, but providing them as strings. Yes, we do this with call_user_func but that's called as a parameter. The proposed syntax is very different to that.

Share:
Laravel jbrooksuk avatar
jbrooksuk
voted no
1

This is a pattern already used in some tools and frameworks like Laravel with pipelines and since we have arrow functions and first-class callable I think this would bring a lot of possibilities to the language.

Also this is already proved really handy on other languages.

Share:
wendell_adriel avatar
wendell_adriel
voted yes
1

I don't love the syntax, but it would be nice to have a first party solution and is more readable than nesting, especially with callable syntax.

Share:
jessarcher avatar
jessarcher
voted yes
1

I also see it as a great addition for first-class callables in PHP and a logical next step for them.

Share:
christophrumpel avatar
christophrumpel
voted yes
1

I don't like the example in the description, but with First-class callable syntax it looks better and more convenient.

Share:
victor-falcon avatar
victor-falcon
voted yes
1

Very good proposal but there are bad examples in RFC. RFC should not use strings as callable.

Share:
raszekster avatar
raszekster
voted yes
1

it's works great in other languages and has a better readability and clearer syntax.

Share:
jeidison avatar
jeidison
voted yes

Check out another RFCs

Interface Default Methods

Interface Default Methods improves backwards compatibility when changing interfaces, but also add a way to have multi-inheritance in PHP.

95
168 yes
264 no
Short Closures 2.0

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.

101
373 yes
66 no
Property Hooks

A new way of interacting with properties

65
125 yes
81 no
RSS Feed Contribute Watch on YouTube Our License
© 2024 RFC Vote. This project is open source. Contribute and collaborate with us!