The Pipe Operator

Read the RFC Externals
87
253 yes
119 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

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
1

I love this idea, but I loathe the syntax. However, I am not clever enough to propose another syntax. My issue with chaining by nesting functions is that it reads backwards, and that's just so visually messy that I end up just setting the variable multiple times for readability alone, which is the desired outcome anyway. It's not like we NEED to be terse in PHP to save a few bytes. Better to have obvious and readable code. So while I'm voting yes for this, it's for concept only, not crazy about the syntax. 🤷‍♀️

Share:
jklmnop avatar
jklmnop
voted yes
1

No benefit, it is also feels bad to use a function name as string when referencing it. Limited usefulness if the via-string-called-function has more than one argument.

Share:
dsentker avatar
dsentker
voted no
1

its syntax is too much complicated

Share:
emreakay avatar
emreakay
voted no
RSS Feed Contribute Watch on YouTube Our License
© 2024 RFC Vote. This project is open source. Contribute and collaborate with us!