alexander's avatar

Alexander Stehlik

alexander

Member since

316

Total Reputation

3

Total Arguments

10

Total Votes for Arguments

Arguments and votes

1

I do not like the notation with the function names as string but apart from that I think it can make processing arrays and strings more painless.

Share:
Read the RFC: The Pipe Operator alexander avatar
alexander
voted yes
6

I think this would be a great improvement.

I prefer this:

$result = "Hello World"
    |> htmlentities(...)
    |> str_split(...)
    |> fn($x) => array_map(strtoupper(...), $x)
    |> fn($x) => array_filter($x, fn($v) => $v != 'O');

instead of this:

$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 william-2 avatar
william-2
voted yes
83

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
64

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
12

I'm not sure if allowing default implementations in interfaces is the way to go here.

To me it looks like a workaround / hack for non existing multi inheritance.

Why not either make multi inheritance possible instead or allow traits with interfaces as suggested by Victor?

Share:
Read the RFC: Interface Default Methods alexander avatar
alexander
voted no
12

It improves the readability and usability of closures that consist of more than one assignment.

Share:
Read the RFC: Short Closures 2.0 alexander avatar
alexander
voted yes
75
  • Interface shall stay light, pure contracts defining expectations, else they are just abstract classes with multi-inheritance.
  • If multi-inheritance is the subject, a specific RFC shall be done on this.
  • An other away might be to dig back this RFC to add interface to traits: https://wiki.php.net/rfc/traits-with-interfaces
Share:
Read the RFC: Interface Default Methods victor avatar
victor
voted no
44

It looks pretty much the exact function as abstract class. I still think interfaces/contracts should not include any concrete implementation

Share:
Read the RFC: Interface Default Methods nabeel avatar
nabeel
voted no
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
121

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
RSS Feed Contribute Watch on YouTube Our License
© 2024 RFC Vote. This project is open source. Contribute and collaborate with us!