On 15-6-2023 5:47, Levi Morrison via internals wrote:
Hello, PHP Internals,

I am moving my RFC for interface default methods to discussion:
https://wiki.php.net/rfc/interface-default-methods.

This can be a useful tool for a few reasons:
  1. It can make implementing an interface easier when certain methods
can be implemented by other methods in the interface. For example, if
`Countable` had an `isEmpty(): bool` method, it could be implemented
by doing `$this->count() > 0`. Of course, if an implementation can be
more efficient, they are still free to implement it how they want.
  2. It can mitigate BC breaks in some cases. It's somewhat common for
authors to want to expand new methods onto existing interfaces over
time. Although this would still be a BC break, it moves it from a
massive change (every single implementor must add something, even if
it's a stub, or it will fail to compile) to a naming collision issue
only (only classes which already had a method of the same name will
fail to compile).

There is prior art for this feature in both Java and C#. There may be
other languages, but I was aware of at least these.

Note that the RFC links to a partial implementation. If there are two
or more interfaces with default methods of the same shape (name, args,
etc) and a class implements both interfaces and doesn't provide a
concrete implementation, which default implementation should be
chosen? There is a proposal for resolving this in some cases which is
modelled after Java's implementation, but it isn't implemented.

Thank you for your time. I look forward to productive feedback.

Levi Morrison


Hi Levi,

Thanks for the RFC. The usecase seems clear.

There are two things I'm missing on an initial read of the RFC.

> Adding a default implementation to an existing interface method will not break existing code, because every existing usage has a higher priority than the default.

A: How would this work if the existing method in the implementing class has a different function signature than the newly introduced method in the interface ?
There are two aspects to this:
1. What if the existing method has different parameters ?
2. What if the existing method has the same parameters, but different/incompatible parameter/return types ?

B: How does the ability to add default method implementations to an interface compare to providing an abstract class implementing the interface and providing the default method implementations ?

Smile,
Juliette


Reply via email to