Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120634
MIME-Version: 1.0
References: <CAAKU0umNOJ+6x44WRuzc2e9_5sDehAq5UB_aFn+cT4wxTny9wg@mail.gmail.com>
 <CAAwdEzA3hLRsCaDwo7t0r0_jJmQXvaYnqfDNciu4pDo0KfqanQ@mail.gmail.com> <CAFMT4Nq4FwaReL=Bd0r6EVyUhPHEGTVhmb2fngbV--T1xj0cww@mail.gmail.com>
In-Reply-To: <CAFMT4Nq4FwaReL=Bd0r6EVyUhPHEGTVhmb2fngbV--T1xj0cww@mail.gmail.com>
Date: Tue, 20 Jun 2023 08:21:50 +0300
Message-ID: <CAAwdEzBQLxdPCXgXM1TrjWPcuNBAL9hcNM7uwrWmeHNNhS1hew@mail.gmail.com>
To: Levi Morrison <levim@php.net>
Cc: Levi Morrison <levi.morrison@datadoghq.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000001652cc05fe88d5dc"
Subject: Re: [PHP-DEV] [RFC] Interface Default Methods
From: drealecs@gmail.com (=?UTF-8?Q?Alexandru_P=C4=83tr=C4=83nescu?=)

--0000000000001652cc05fe88d5dc
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Jun 20, 2023 at 7:30=E2=80=AFAM Levi Morrison <levim@php.net> wrote=
:

> On Sat, Jun 17, 2023 at 6:05=E2=80=AFAM Alexandru P=C4=83tr=C4=83nescu <d=
realecs@gmail.com>
> wrote:
> >
> > 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?
>
> 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.
>

Looks good to me. Thank you!


>
> > 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 interfac=
e?
>
> 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.
>

Yes, that looks good, this was the first question, exactly.


Sorry for the lack of clarity in my second question.
Is it if it would be allowed to have something like:

trait Trait1 {
function method1() { echo __METHOD__, "\n"; }
}

interface Interface1 {
use Trait1;
function method1();
}

So both trait and interface can be used independently without code
duplication.

A more complex scenario where this might be useful:

// external package
interface Interface1 {
function method1();
}
interface Interface2 {
function method2();
}

// internal package
trait Trait1 {
function method1() { echo __METHOD__, "\n"; }
}
trait Trait2 {
function method2() { echo __METHOD__, "\n"; }
}
interface Interface3 extends Interface1, Interface2 {
use Trait1;
use Trait2;
}

Where it will allow either usage of a class for:
- Interface1 with Trait1
- Interface2 with Trait2
- Interface3 that would already have the method implemented.

Hope it's clearer now.
I don't know if we want to support use of a trait in the interface
but I think the RFC should mention that it is or is not supported.

Thank you,
Alex

--0000000000001652cc05fe88d5dc--