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

Initially I had exact the same opinion as other folks voting no: "Separation of ..." , "Interface must not include ...".

Reading this internals.io thread which I highly recommend to read I realized that yes, these arguments were drilled in me in university times.

Second, the more I read about traits the more I understand that it drags down modern PHP as a language, being just "copy paste" code. So I think traits in general must be discouraged to be used in situations they don't fit.(Saying this because see some folks really abusing traits).

Third I discussed with my C# colleagues and they all like default methods as feature, which makes me think, its not that bad.

Share:
vandal avatar
vandal
voted yes
1

I my perspective interfaces should be stay as it is. They are skeletons and nothing much. If something like this needed, we already got abstract classes. Only down side of the abstract classes is that you can not extend multiple classes at one time, but in this situation traits with abstracts got your back.

Share:
megasteve19 avatar
megasteve19
voted no
1

but also add a way to have multi-inheritance in PHP.

I consider that allowing multiple inheritance is a mistake, since inheritance is something that in more than 90% of cases is a premature and erroneous abstraction of reality.

Share:
khru avatar
khru
voted no
1

Traits already cover the use case.

Share:
kyriakos avatar
kyriakos
voted no
1

I like how this solves updating existing interfaces without breaking user facing code.

Share:
thomasalrek avatar
thomasalrek
voted yes
1

C# has it and I want it in PHP too. It is very handy for implementing new interfaces with simple getters for example.

Share:
ricardo avatar
ricardo
voted yes
1

I'm against a multi-inheritance in OOP. I don't think this RFC is necessary for the language. The current OOP system in PHP is already well developed.

Share:
Contributor serhii avatar
serhii
voted no
1

if you need a default method implementation, then use an abstract class. And inheritance, especially multiple, contradicts half of the principles of SOLID. Use composition whenever you can and you will be happy.

Share:
stolentine avatar
stolentine
voted no
1

We already have solutions to both problems, with traits and class inheritance.

Share:
thallisphp avatar
thallisphp
voted no
1

The promised backwards compatability was never a real feature. You can still get name clashes with existing methods. So its a new feature promising something that will never happen. It got rejected for good reasons.

Share:
tpetry avatar
tpetry
voted no
1

Brings ambiguity, violates single responsibility. Interfaces for contracts, handle defaults with concrete/abstract classes. Code becomes clearer, more maintainable.

Share:
phcostabh avatar
phcostabh
voted no
1

I've written DefaultImplementation traits to implement common interface functionality one too many times. Would love to see this as a feature.

Share:
moebrowne avatar
moebrowne
voted yes
1

it works in other languages pretty well, and i think it's not a bad thing to have more than one way to do something.

Share:
roeycohen avatar
roeycohen
voted yes
1

This seems like a solution to a design problem rather than a language problem. I feel like the specific examples aren't something that I've come across frequently enough to add to the language. If we're looking at a pure OOP perspective, Interfaces enforce behaviour. If you're also supplying the behaviour in cases where you don't expect there to always need to be an implementation that really smells like a poorly designed interface.

Share:
nathansalter avatar
nathansalter
voted no
1

With our current definition of an interface this RFC seems silly - but i really think that this could allow for faster and easier development (less files, less duplicated code...).

Just today while coding i had an example of an interface where one of the abstract functions would be the same 99% of the time. Creating a trait for a 4 liner function seems overkill - but the alternative is to duplicate the code almost everytime.

Share:
simonvanacco avatar
simonvanacco
voted yes

Check out another RFCs

Asymmetric Visibility v2

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

21
21 yes
38 no
The Pipe Operator

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

93
272 yes
131 no
new MyClass()->method() without parentheses

Chain method on newly created objects without parentheses

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