Interface Default Methods improves backwards compatibility when changing interfaces, but also add a way to have multi-inheritance in PHP.
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.
Interface should be an interface, not an implementation
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.
An Interface should define the behavior of a Concrete class.
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.
Interfaces look good in current form.
Because it violates the OOP principle of abstraction
Interface should be contract which a class must fulfill. They should not include any implementation. If you want share implementation you can use traits.
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).
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.
I'd like the functionality, although I'd probably prefer to extend multiple classes.
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.
There is absolutely no need to mix interfaces with abstract classes. interfaces/contracts should not include any concrete implementation.
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
it will be beneficial for my packages
The "pipe operator" |>
allows you to chain multiple function calls in a more convenient way.
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.