Noah van Bochove

It is really confusing to read since having the space breaks the way PHP handles spaces in all other places. It is incoherent.

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.

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.

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.

• 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

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

1. Separation of what (interface) and how (class/trait)
2. More balanced vote chart, now it's too green