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%
75
  • 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
Share:
victor avatar
victor
voted no
57
  1. Separation of what (interface) and how (class/trait)
  2. More balanced vote chart, now it's too green
Share:
jacek avatar
jacek
voted no
55

I wrote down some thoughts on this RFC on my blog. I think it's worth rethinking our current definition of what "an interface" is. Especially since many languages are interface default methods as their way of multi-inheritance.

Share:
Contributor brent avatar
brent
voted yes
44

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

Share:
nabeel avatar
nabeel
voted no
39

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

Share:
marc avatar
marc
voted yes
17

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.

Share:
marco avatar
marco
voted yes
12

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?

Share:
alexander avatar
alexander
voted no
10

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!

Share:
eugen avatar
eugen
voted yes
8

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

Share:
Carakas avatar
Carakas
voted yes
7

The only purpose of interface is to put restriction on architecture.

With interface we define how our code will be dealing with any "external" code - any code that does not know about implementation details. It can be system that uses our library, or just another module in our project decoupled from what is covered by an interface.

So interface is just a boundary, to keep things separated and protect it from unexpected changes.

We show only interfaces to "outer world" and that gives us freedom to make any changes to implementation details.

As long as we don't change interface itself, "outer" code must not change. So "outer" code is isolated and we benefit from that - the less changes we should make, the less error we do and less work overall.

It is the superpower and real purpose of existing of interfaces.

What if interface provide default implementation? It will change when we change the implementation details, so will change - and sometimes break - outer code. And isolation is no longer the case. Changing implementation details in our code we break outer code.

And interfaces with default implementation instantly loose its superpower.

From an architecture tool interface turns to dangerous and unpredictable creature.

So No. I don't want this RFC.

Share:
Леонид Черненко avatar
Леонид Черненко
voted no
6

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

Share:
arziel avatar
arziel
voted yes
5

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

Share:
alex avatar
alex
voted yes
3

Sounds like a potential to mix up what's an interface and what's an abstract class

Share:
duncancummingathostelworldcom avatar
duncancummingathos...
voted no
3

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

Share:
marko avatar
marko
voted no
2

There are so many other, more elegant solutions to this problem that could solve it; multi-class-inheritance, traits-implementing-interfaces, etc. all to solve a problem I haven't really found myself running into more than once or twice in a number of years.

Share:
liam avatar
liam
voted no

Check out another RFCs

The Pipe Operator

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

93
272 yes
131 no
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
Asymmetric Visibility v2

A new syntax for declaring the “set” operation visibility of an object property

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