Interface Default Methods improves backwards compatibility when changing interfaces, but also add a way to have multi-inheritance in PHP.
Prevents having to add a trait to every class that has to implement an interface, being able to provide default implementations via interfaces would be a large DX improvment
Most of the time when creating an Interface that shares some implementation we would always create Interface + Trait. This is just more work. With Interface default methods we would get rid of the Trait and be able to have it in the interface already!
it's works great in other languages like java and kotlin.
It's possible to improve backwards compatibility without default method implementations in interfaces.
Similar concept exists in Kotlin, Swift (extend protocols), Java, C#, and other languages, and it has proven to be quite useful in those ecosystems.
I understand the downside of not having multi-inheritance available in PHP. However, IMHO this should not be solved by allowing implementation specific code in interfaces. That's not what interfaces are meant for.
Interfaces are contracts. No implementations should be allowed.
I don't think we need to add business logic to interfaces. Interfaces are contracts, that's the whole beauty of interfaces (that, and the fact that they encourage composition over inheritance, which imo leads to code that is easier to maintain). Having default methods would pollute that premise.
We can already do this with abstract classes. I believe Interfaces should be contracts that leave the implementations up to the implementing classes.
If I have an interface with getItem(), hasItem() and a findItem() methods , it would like to provide a default implementation for hasItem() and getItem() that use findItem().
This way I don't need to create a trait for this .
Interfaces should define contracts and stop there. Concrete behavior, even as simple as the log example by Brent, should be implemented on an abstract class or on specific classes.
An interface should only describe a contract that a class must adhere to and nothing else. If there is a commonly repeated segment of code to implement part of an interface, I believe that this can be covered with a trait, as it is clearly opinionated in how this interface should be implemented.
My vote is towards being able to add interfaces to traits.
Interfaces should only give the form of the class that implements it, not its implementation. This is the role of abstract classes.
I think this is very useful for PHP library developers.
They can add methods and provide a default implementation without breaking code (and if they only throw an exception).
For example Doctrine could add a
addAll method to the Collection interface and provide a basic implementation that uses the existing
add method under the hood.
Since interfaces (in other programming languages) don't add member fields, the
this won't need to be adjusted (by an offset) and the interface default methods just get added to the virtual method table (vtable) of the class, if they are not implemented by the class.
This is what an abstract class is for. Using Brents blog example, you'd create a default instance which was an abstract, this abstract would implement the default methods and the interface.