Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120591
MIME-Version: 1.0
References: <CAAKU0umNOJ+6x44WRuzc2e9_5sDehAq5UB_aFn+cT4wxTny9wg@mail.gmail.com>
In-Reply-To: <CAAKU0umNOJ+6x44WRuzc2e9_5sDehAq5UB_aFn+cT4wxTny9wg@mail.gmail.com>
Date: Thu, 15 Jun 2023 12:08:36 -0300
Message-ID: <CADK1yXKwdpHtZBbKZRHwfJUxJoM19LtjiyKOFvAiyCTYjc+xyA@mail.gmail.com>
To: Levi Morrison <levi.morrison@datadoghq.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000737d2a05fe2c737b"
Subject: Re: [PHP-DEV] [RFC] Interface Default Methods
From: deleugyn@gmail.com (Deleu)

--000000000000737d2a05fe2c737b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I loved the proposal and I think this has the potential to be a huge
developer experience improvement, perhaps at least as great as property
constructor promotion and match().

Just a side note though, in the Backward Compatibility section, I would
think that only "None" should be declared. From the PHP binary perspective,
running code before and after this change has absolutely 0 impact/breaking
changes.
The feature may introduce a new way for *Users of PHP* to break BC with
*Other Users of PHP*. The language change itself has no impact on PHP code
written prior to the feature. The additional note about how users may break
BC by using the feature would be a description of the feature itself, thus
might be best declared as part of the Proposal instead.

I wish us all the best of luck with this proposal.

On Thu, Jun 15, 2023 at 12:48=E2=80=AFAM Levi Morrison via internals <
internals@lists.php.net> 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

--=20
Marco Deleu

--000000000000737d2a05fe2c737b--