Interface Default Methods

Read the RFC
95
168 yes
264 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!
39%
61%
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

Interface should not contain implementations

Share:
tomsix avatar
tomsix
voted no
1

An interface is a contract, that should define what the behaviour of an object is. If you need default methods, use an abstract class that implements said interface. If you require more than one abstract class, you can use traits, or your class structure is probably wrong

Share:
nathan avatar
nathan
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

Check out another RFCs

Short Closures 2.0

This RFC proposes a way to have multi-line short closures — closures that don't need explicit use statements, but can still have multiple lines and a return statement.

101
373 yes
66 no
new MyClass()->method() without parentheses

Chain method on newly created objects without parentheses

38
51 yes
13 no
The Pipe Operator

The "pipe operator" |> allows you to chain multiple function calls in a more convenient way.

90
262 yes
126 no
RSS Feed Contribute Watch on YouTube Our License
© 2024 RFC Vote. This project is open source. Contribute and collaborate with us!