Thomas Klein

lgtm

RFC shouldn't be a place to propose new syntax because laravel is messy

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.

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

The idea is a nice one, and one that I would welcome, but this proposal puts forward messy syntax that isn't clear!

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.

• 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