noah's avatar

Noah van Bochove

noah

Member since

100

Total Reputation

1

Total Arguments

6

Total Votes for Arguments

Arguments and votes

7

In my opinion the solution as is proposed is ambigious because you would have to guess the variable names and these variables by themselfs only suggest their functionality. Like other langauge constructs which have specific keywords or syntax. The concept I support but this variant I do not.

Share:
Read the RFC: Property Hooks noah avatar
noah
voted no
24

The 'use' statement clarifies the scope for me. So a proposal like this could have the side effect of mixing scope which would lead to a confusing code.

Share:
Read the RFC: Short Closures 2.0 nabeel avatar
nabeel
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
74
  • 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
43

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
56
  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!