Interface Default Methods

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.

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.

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.

Traits already cover the use case.

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

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

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.

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.

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

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.

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

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

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.

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.

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.