Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120604
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-496-g8c46984af0-fm-20230615.001-g8c46984a
Mime-Version: 1.0
Message-ID: <6805a0b7-1bd8-41ce-9003-b45d86e191db@app.fastmail.com>
In-Reply-To: 
 <CAAKU0umNOJ+6x44WRuzc2e9_5sDehAq5UB_aFn+cT4wxTny9wg@mail.gmail.com>
References: 
 <CAAKU0umNOJ+6x44WRuzc2e9_5sDehAq5UB_aFn+cT4wxTny9wg@mail.gmail.com>
Date: Fri, 16 Jun 2023 17:18:07 +0000
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: Re: [PHP-DEV] [RFC] Interface Default Methods
From: larry@garfieldtech.com ("Larry Garfield")

On Thu, Jun 15, 2023, at 3:47 AM, 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.

This would essentially replace the semi-common pattern of providing an interface, and a trait that implements most of the interface for you.

I have many conflicting thoughts on this RFC.

On the plus side, the flexibility it provides sounds delightful, and it would effectively render abstract classes almost entirely pointless.

On the down side, multiple inheritance is often avoided for a reason, and as Ilija noted it doesn't *completely* replace traits and base classes as it doesn't apply to non-public methods.

From a BC perspective it seems fine.  It's at worst the same as now, and potentially makes extending existing interfaces easier.

I think I am overall positive, but still a bit uneasy and having a hard time articulating why.

--Larry Garfield