Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120633
MIME-Version: 1.0
References: <CAAKU0umNOJ+6x44WRuzc2e9_5sDehAq5UB_aFn+cT4wxTny9wg@mail.gmail.com>
 <CAAwdEzA3hLRsCaDwo7t0r0_jJmQXvaYnqfDNciu4pDo0KfqanQ@mail.gmail.com>
In-Reply-To: <CAAwdEzA3hLRsCaDwo7t0r0_jJmQXvaYnqfDNciu4pDo0KfqanQ@mail.gmail.com>
Date: Mon, 19 Jun 2023 22:30:15 -0600
Message-ID: <CAFMT4Nq4FwaReL=Bd0r6EVyUhPHEGTVhmb2fngbV--T1xj0cww@mail.gmail.com>
To: =?UTF-8?Q?Alexandru_P=C4=83tr=C4=83nescu?= <drealecs@gmail.com>
Cc: Levi Morrison <levi.morrison@datadoghq.com>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] Interface Default Methods
From: levim@php.net (Levi Morrison)

On Sat, Jun 17, 2023 at 6:05=E2=80=AFAM Alexandru P=C4=83tr=C4=83nescu <dre=
alecs@gmail.com> wrote:
>
> Thank you for this!
> I like the proposal and I think it fits well.
> I'm used to it from Java and I don't know any reason for it to be
> considered a bad practice since it was introduce, about 9-10 years ago.
>
> 1. Do we want to allow also private methods in the interface so that it
> allows code reuse or better code organization in smaller methods? Java
> introduced this only in the next version.
> The private methods would be invisible to implementing classes and to
> anything else, of course.
> We can also add them at a later point but it might be better to have the
> feature complete now.
>
> Sidenote: I don't think protected method should ever exist on interfaces;
> that should remain for abstract classes use case.

Sorry for the delay in responding to your message. I have implemented
support for private methods for people to experiment with. As far as I
can tell, it works as expected and I don't see any issues with them.
Of course, they only make sense as helper methods to the public
default methods.

I'd like to hear what others think about allowing private interface
methods that have method bodies, but I think it's easy and sensible.

> 2. The only use case for myself for ever using traits would be if traits
> would offer a default implementation for an interface. Now with a default
> implementation offered by interface itself, sounds even better.
> However, I can see how there could be more than one provided default
> implementation that can be offered.
> Would a method implemented by a trait have higher precedence over the
> interface default implementation?
> Would a trait offered implementation be directly usable by the interface?

I'm not entirely sure what you are asking about traits, so I'll try to
clarify. In a class which uses a trait to implement an interface, that
trait method will take priority over the interface's default method. I
will add a test to the PR to make this more obvious.