alex's avatar

Alex

alex

Member since

132

Total Reputation

1

Total Arguments

10

Total Votes for Arguments

Arguments and votes

2

Maybe if the function names didn't need to be in quotes... As it is certainly not.

Share:
Read the RFC: The Pipe Operator enumag avatar
enumag
voted no
79

With First-class callable syntax available since 8.1, it would now be possible to write it as below, which is much better then string names of functions:

$result = "Hello World"
    |> htmlentities(...)
    |> str_split(...)
    |> fn($x) => array_map(strtoupper(...), $x)
    |> fn($x) => array_filter($x, fn($v) => $v != 'O');
Share:
Read the RFC: The Pipe Operator pronskiy avatar
pronskiy
voted yes
63

For me, the most important argument is that the pipeline pattern is a tried and tested pattern, that this RFC builds upon. A couple of examples:

This RFC adds syntax to make using these kinds of pattern much more convenient.

On top of that, there's the argument that multiple modern languages support a pipe operator:

Finally, I've had numerous occasions where a pipe operator would simplify my own code — I have more than a handful real life cases where this would be useful.

Share:
Read the RFC: The Pipe Operator Contributor brent avatar
brent
voted yes
39

PHP is evolving. There are new concepts added to many programming languages to ease writing and reading (more important!). PHP should focus more on developer experience (but not for legacy projects that get never upgraded to PHP 8+).

Share:
Read the RFC: Short Closures 2.0 eugen avatar
eugen
voted yes
5

I personally don't need it but I guess it could be useful to people.

Share:
Read the RFC: Interface Default Methods alex avatar
alex
voted yes
17

Multi-inheritance seems to be the hot topic that prevented this RFC from being approved even though it was not the RFC target. Multi-inheritance is an afterthought that may or may not be abused with this change. What we want would actually be just the convenience of doing what Traits already allow while reducing potential BC break impact coming from interface changes. There are interfaces originated from the interface segregation mindset that often has only 1 implementation and could very well take advantage of default implementation for a simpler system design.

Share:
Read the RFC: Interface Default Methods marco avatar
marco
voted yes
81

We spend a lot more time reading code than writing it. The elegance of short closure combined with the convenience of variable scope usage has already shown to be a game changer on Typescript and there doesn’t seem to be any technical issue with having it on PHP.

Share:
Read the RFC: Short Closures 2.0 marco avatar
marco
voted yes
120

At least once a week, I throw away an array_map because it ended up looking too bloated and go with a classic foreach instead. Short Closures 2.0 without the use(...) block would've solved this problem, just 2 votes...

Share:
Read the RFC: Short Closures 2.0 davi avatar
davi
voted yes
40

Creating traits for default implementation is just a pain. I want syntactic sugar

Share:
Read the RFC: Interface Default Methods marc avatar
marc
voted yes
55

I wrote down some thoughts on this RFC on my blog. I think it's worth rethinking our current definition of what "an interface" is. Especially since many languages are interface default methods as their way of multi-inheritance.

Share:
Read the RFC: Interface Default Methods Contributor brent avatar
brent
voted yes
RSS Feed Contribute Watch on YouTube Our License
© 2024 RFC Vote. This project is open source. Contribute and collaborate with us!