Adrián Martín

A breakthrough for language, easy to write easy to read.

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?

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

I really love short closure. JS solve this

This sounds like C++ Multi-Inheritence with extrasteps. Please don't.

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.

Classic closure is perfect for this kind of use case

As with all other RFC with 'adding' behaviour, if you don't like it, just don't use it and left it for others :))

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

Just look at how other languages solve this. C# for example. Make short closures like that.

Technically writing a trait isn't a showstopper, but it adds cognitive load because the developer now must know/remember using this Interface requires adding this Trait. PHP should focus more on development experience!

PHP is evolving. There are new concepts added to many programming languages to ease writing and reading (more important!). PHP should focus more on developer experience (but not for legacy projects that get never upgraded to PHP 8+).

I personally don't need it but I guess it could be useful to people.

It will solve having to create traits to add a default implementation when creating interfaces and keeping it nicely together improving the DX

Multi-inheritance seems to be the hot topic that prevented this RFC from being approved even though it was not the RFC target. Multi-inheritance is an afterthought that may or may not be abused with this change. What we want would actually be just the convenience of doing what Traits already allow while reducing potential BC break impact coming from interface changes. There are interfaces originated from the interface segregation mindset that often has only 1 implementation and could very well take advantage of default implementation for a simpler system design.

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.

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...

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

Creating traits for default implementation is just a pain. I want syntactic sugar