Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120737
MIME-Version: 1.0
References: <CAFMT4Nq3y+XKUP7aG7F7aht1DdM7dpqxMT-hcS+Nyvc9FaT=+A@mail.gmail.com>
 <CABdc3WoWSEP0Nu_KEyzSbBAkyZkY+m+bJroBBpJge9SbB4VPNQ@mail.gmail.com> <3a3e7781-c2b4-2880-8048-d19458ac287d@heigl.org>
In-Reply-To: <3a3e7781-c2b4-2880-8048-d19458ac287d@heigl.org>
Date: Mon, 3 Jul 2023 14:45:18 +0200
Message-ID: <CABdc3WqzfrXFG9W61oEVbCC7jaOABabgkcKUM5Q6pAJfJAjJ3g@mail.gmail.com>
To: Andreas Heigl <andreas@heigl.org>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="0000000000009f6e0205ff948a35"
Subject: Re: [PHP-DEV] [VOTE] Interface Default Methods
From: michal.brzuchalski@gmail.com (=?UTF-8?Q?Micha=C5=82_Marcin_Brzuchalski?=)

--0000000000009f6e0205ff948a35
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

pon., 3 lip 2023 o 14:26 Andreas Heigl <andreas@heigl.org> napisa=C5=82(a):

> Hey Micha=C5=82
>
> On 03.07.23 13:32, Micha=C5=82 Marcin Brzuchalski wrote:
> > Hi Levi,
> >
> > pon., 3 lip 2023 o 02:11 Levi Morrison <morrison.levi@gmail.com>
> napisa=C5=82(a):
> >
> >> Chatter on the [Interface Default Methods RFC][1] has been quiet for
> >> the past 6 days, and the feature freeze deadline is fast approaching
> >> for PHP 8.3, so I'm moving this to vote. It'll be open for two weeks
> >> as usual.
> >>
> >> Thanks to everyone who discussed weaknesses in the RFC during the
> >> discussion phase.
> >>
> >>    [1]: https://wiki.php.net/rfc/interface-default-methods
> >
> >
> > I voted "yes", my personal use case waits for this feature. My use
> > case example:
> >
> > https://gist.github.com/brzuchal/89e9481bbd34a6ce3d95a68eabff038b
>
> I've added two already possible solutions to that as comments.
> >
> > With interface default methods I'd no longer need traits that implement=
 a
> > single or in rare cases 2 methods that
> > use their respective methods returning objects and iterate in Generator
> > fashion over a paginated result set.
> > This is not an issue if there is one implementation of the interface bu=
t
> > when I decorate to apply some:
> > * caching
> > * logging
> > * failover
>
> That requires that you are in control over both the interface AND the
> implementation. In which case you probably do not need an interface and
> the Trait would be enough (using `abstract public function` in traits
> works after all)
>
> So you could even skip the implements part.
>
> As the interface should be designed specifically to be
> implementation-agnostic, adding implementation to the interface is
> counter-productive.
>
> Adding abstract methods to a trait and then just adding the traits is no
> issue at all especially when you are in control of the interface AND the
> implementation.
>
> When you are NOT in control of the interface... well, you can't expect
> to have a default implementation and I am already looking forward to the
> complaints that it is great to have a default implementation, but not
> *that* one.
>
> There is a reason why the respective construct in Rust (which was
> mentioned in the RFC) is called a Trait and not an Interface.
>
> So to decouple the contract from the implementation it is necessary that
> no implementation is part of the contract.
>
> >
> > then the trait has to be attached to every class besides that it has to
> > exist which is an additional symbol here.
>
> Stop using `implements` at all and solely rely on `use`.
>

I use an interface for mocks in unit tests.
A default interface method allows me to remove some traits which are not my
favorite and I'd like to remove them all.
Turning the interface into an abstract class adds an inheritance that I
want to avoid.
Given that, it true is that it is possible to solve the problem differently
but not without side effects (either lack of contract or inheritance).

Cheers,
Micha=C5=82 Marcin Brzuchalski

--0000000000009f6e0205ff948a35--