Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120593
To: internals@lists.php.net
References: <CAAKU0umNOJ+6x44WRuzc2e9_5sDehAq5UB_aFn+cT4wxTny9wg@mail.gmail.com>
 <648AAE1D.9070805@adviesenzo.nl>
 <CAAKU0uk=tKzzaGRJAF+7WaT-3CbCwjJbHFbc4WCqCRK_9+OOgw@mail.gmail.com>
Message-ID: <648B30B5.50705@adviesenzo.nl>
Date: Thu, 15 Jun 2023 17:39:33 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.0
MIME-Version: 1.0
In-Reply-To: <CAAKU0uk=tKzzaGRJAF+7WaT-3CbCwjJbHFbc4WCqCRK_9+OOgw@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------020601000109040103070603"
Subject: Re: [PHP-DEV] [RFC] Interface Default Methods
From: php-internals_nospam@adviesenzo.nl (Juliette Reinders Folmer)

--------------020601000109040103070603
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

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

--------------020601000109040103070603--