Re: [RFC] Interface Default Methods

On 15-6-2023 16:52, Levi Morrison via internals wrote:

On Thu, Jun 15, 2023 at 12:22 AM Juliette Reinders Folmer <php-internals_nospam@adviesenzo.nl> wrote:

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

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

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 ?

You mis-interpreted what I was trying to say, so I'll try to clarify that first, and then secondly address your question. If there an existing interface, say:

     interface Interface1 { function method1(); }

The RFC is saying that if you added a default implementation to method1 without changing its signature at all, then that would not be a compatibility issue. All existing implementers have somehow implemented this method already, so adding a default will do nothing (it will be unused). As to your questions about incompatible signatures, it's not any different from any other interface method. If you add a new method to the interface, and it's not compatible with some existing method on an implementer, then it's a compatibility issue. That's not changing with default methods. What is changing is that if a new method is added to an interface, and it has a default implementation, it's way less likely to be a compatibility break, because we only have to worry about methods that share the same name. Without default methods, essentially all additions would be compatibility break.

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 ?

A key difference is that you can implement many interfaces, but can only extend a single class (abstract or not). For this reason, many contracts are formed with interfaces and relatively fewer with abstract classes. Well, that's my experience, anyway.

Fair enough and thank you for your response. You were right, I copy/pasted the wrong sentence to quote. I still believe this information should be added to the RFC as the risk of adding new methods to an interface which collide with existing methods in implementations of that interface is very real, though I agree with Deleu that this BC impact is not so much of the RFC, but of what can happen once the RFC would be accepted. While I can understand the tendency to defer this question to "that's an issue for userland when userland adds new methods to existing interfaces" (or PHP itself if new methods would be added to PHP native interfaces), I don't think that's fair as this RFC is the one which opens the door to that possibility. Smile, Juliette