Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120583
To: internals@lists.php.net
References: <CAAKU0umNOJ+6x44WRuzc2e9_5sDehAq5UB_aFn+cT4wxTny9wg@mail.gmail.com>
Message-ID: <648AAE1D.9070805@adviesenzo.nl>
Date: Thu, 15 Jun 2023 08:22:21 +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: <CAAKU0umNOJ+6x44WRuzc2e9_5sDehAq5UB_aFn+cT4wxTny9wg@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------040109070003090605050101"
Subject: Re: [PHP-DEV] [RFC] Interface Default Methods
From: php-internals_nospam@adviesenzo.nl (Juliette Reinders Folmer)

--------------040109070003090605050101
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

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



--------------040109070003090605050101--