Interface Default Methods

Read the RFC
93
169 yes
258 no

Interface Default Methods improves backwards compatibility when changing interfaces, but also add a way to have multi-inheritance in PHP.

Click the bar to cast your vote!
40%
60%
2

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

Share:
sandermuller avatar
sandermuller
voted yes
2

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!

Share:
wendell_adriel avatar
wendell_adriel
voted yes
2

it's works great in other languages like java and kotlin.

Share:
jeidison avatar
jeidison
voted yes
2

It's possible to improve backwards compatibility without default method implementations in interfaces.

Share:
smilimko avatar
smilimko
voted no
2

Similar concept exists in Kotlin, Swift (extend protocols), Java, C#, and other languages, and it has proven to be quite useful in those ecosystems.

Share:
pronskiy avatar
pronskiy
voted yes
2

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.

Share:
bob avatar
bob
voted no
2

Interfaces are contracts. No implementations should be allowed.

Share:
pedro avatar
pedro
voted no
2

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.

Share:
denis avatar
denis
voted no
2

We can already do this with abstract classes. I believe Interfaces should be contracts that leave the implementations up to the implementing classes.

Share:
rob-1 avatar
rob-1
voted no
1

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 .

Share:
johanv avatar
johanv
voted yes
1

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.

Share:
flavioheleno avatar
flavioheleno
voted no
1

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.

Share:
sam-moffat avatar
sam-moffat
voted no
1

Interfaces should only give the form of the class that implements it, not its implementation. This is the role of abstract classes.

Share:
ugo-brocard avatar
ugo-brocard
voted no
1

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.

Share:
maz avatar
maz
voted yes
1

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.

Share:
letssurf avatar
letssurf
voted no
RSS Feed Contribute Watch on YouTube Our License
© 2024 RFC Vote. This project is open source. Contribute and collaborate with us!