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%
1

I've seen that C# and Java do have this kind of logic. I've also spent a few seconds to read the blog post from brent.

Yes, there are use-cases where default methods might be helpful. But the same argument given in the blog post regarding "how many implementations will look other than..." can be given with "how many interfaces have this kind of abstraction".

So how many default methods will be around if we support this kind of "feature"? If that only applies to LoggerInterface since its design allows us to easily provide default methods, I don't see a benefit here. Most interface methods are usually not simple proxies to other interface methods and thus thats barely useful.

Share:
boesing avatar
boesing
voted no
1

Interface should be an interface, not an implementation

Share:
check24-axel-nitzsche avatar
check24-axel-nitzs...
voted no
1

As written this feels too close to multiple inheritance. We already have traits. Why not allow an interface to reference a trait as the default implementation and then allow a class to optionally use that trait through the interface reference.

Share:
jstoks avatar
jstoks
voted no
1

An Interface should define the behavior of a Concrete class.

Share:
andi avatar
andi
voted no
1

Just add this and get rid of abstract classes and traits to make the language simpler, method conflicts resolution is not a big issue as it's already done in traits, also python, C#, Java, Kotlin all have a similar feature so I don't see what's the big deal with PHP as no developer will say that PHP is cleaner.

Share:
sidux avatar
sidux
voted yes
1

Interfaces look good in current form.

Share:
mcek avatar
mcek
voted no
1

Because it violates the OOP principle of abstraction

Share:
bbldn05 avatar
bbldn05
voted no
1

Interface should be contract which a class must fulfill. They should not include any implementation. If you want share implementation you can use traits.

Share:
yoshi129 avatar
yoshi129
voted no
1

I read the LoggerInterface example but still dislike this RFC, sorry. It's not your business to know if all every methods use "log" or not.

So I will say like many said before me : if you want implementation, use abstract classes (or Trait).

Share:
davg avatar
davg
voted no
1

While I see there's a case for it and that it could be useful in certain cases, I don't think this will improve our code when looking at the bigger picture. Not being able to add a default implementation in your interface is a feature and not a shortcoming in my opinion.

I'm perfectly fine with combining interfaces and traits to accomplish the same thing.

Share:
timvandijck avatar
timvandijck
voted no
1

I'd like the functionality, although I'd probably prefer to extend multiple classes.

Share:
jessarcher avatar
jessarcher
voted yes
1

Interfaces are not intended to dictate how something is implemented. Perhaps this is a conversation for another type of architecture?

I don't understand the struggle with just using a Trait or extending an Abstract class that implements a specific Interface when you need it. That's what they're there for.

Share:
jklmnop avatar
jklmnop
voted no
1

There is absolutely no need to mix interfaces with abstract classes. interfaces/contracts should not include any concrete implementation.

Share:
dsentker avatar
dsentker
voted no
1

this makes a mess of concerns and responsibility, interface is a contract for what a class needs to implement not should implement

default implementations belong more to abstract classes

Share:
pintend avatar
pintend
voted no
1

it will be beneficial for my packages

Share:
emreakay avatar
emreakay
voted yes

Check out another RFCs

Property Hooks

A new way of interacting with properties

70
141 yes
90 no
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
RSS Feed Contribute Watch on YouTube Our License
© 2024 RFC Vote. This project is open source. Contribute and collaborate with us!