D's avatar

D

D

Member since

87

Total Reputation

1

Total Arguments

7

Total Votes for Arguments

Arguments and votes

6

No clear benefit and the syntax is simply just too messy.

Share:
Read the RFC: The Pipe Operator D avatar
D
voted no
34

I see no immediate benefit of the proposed solution over the userland implementations. The RFC mentions a shopping cart example, but I don't think that's cleaner than using league/pipeline or Laravel's pipeline.

It's a bit messy for the simpler examples as well.

Share:
Read the RFC: The Pipe Operator ju5t avatar
ju5t
voted no
17

It's almost as messy as putting all the functions into each other.

Share:
Read the RFC: The Pipe Operator t avatar
t
voted no
13

I really do not want to see this in PHP because it tempts to apply closures on everything. The question is not if we can but if we should.

Share:
Read the RFC: Short Closures 2.0 marko avatar
marko
voted no
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
57
  1. Separation of what (interface) and how (class/trait)
  2. More balanced vote chart, now it's too green
Share:
Read the RFC: Interface Default Methods jacek avatar
jacek
voted no
RSS Feed Contribute Watch on YouTube Our License
© 2024 RFC Vote. This project is open source. Contribute and collaborate with us!