Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120780
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> <CADK1yX+GMJutCe33i+n6+ftX=KaLxCxYypEbahFqs2SvpAqJ8A@mail.gmail.com>
 <CAPzBOBPZKgsCjQU-WkHF_Qt29T0HtoJwQSYD8yw4qXBAiNprzQ@mail.gmail.com>
 <CABdc3WoTi_gaRvzzjw+=vcySCv7hRTj1FRWmX=wo260QHUodeg@mail.gmail.com>
 <CAPzBOBN+Ny9Cfyyjeq2NH1sZqupbbt1HbOdP=cg4A0uxD0Dttg@mail.gmail.com>
 <308d32d6-c145-4f8c-8779-101a696b60a0@app.fastmail.com> <CAPzBOBPGihd+HNFDaYAO9x+LgGHtZ8r_UDBxS=+jcSHq=DCBPQ@mail.gmail.com>
 <66e67efa-1f41-4971-b070-7785f99ab286@app.fastmail.com>
In-Reply-To: <66e67efa-1f41-4971-b070-7785f99ab286@app.fastmail.com>
Date: Tue, 11 Jul 2023 19:28:06 +0200
Message-ID: <CAPzBOBOr98CrQZpL0yDVeAVrCwx9csWQFfBtjmkvrX9b+E8Khg@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [VOTE] Interface Default Methods
From: landers.robert@gmail.com (Robert Landers)

> Real code I wrote a week ago (specifically, for a series of events in a d=
omain model):
>
> https://gist.github.com/Crell/f5929e2ee44decd4e9353c41874f26c8
>
> Two different interfaces, that I want to be able to check against, but th=
eir implementations are trivial.  One of them is used in 2 classes, the oth=
er in 3.  A base class simply wouldn't work, both because it's semantically=
 incorrect (these events are not all "special cases of" some common definit=
ion, that's not the data model), and because then I couldn't have the class=
 that uses only one of them.  Traits, for now, are the best solution, and t=
his is an approach that gets taken a lot.

Ah, I see. I would have simply created an ErrorResponseCarrier class,
then had PreRouting and PostRouting extend them and implement whatever
other interfaces they needed.

IMHO, using a shared base class reflects the inheritance better
because they are siblings (at least these appear to be logical
siblings out of context, IMHO) and should look like siblings in a
class diagram. Their current dis-jointed-ness strikes me as odd and
the usage of traits in this way strikes me as an anti-pattern. But I
came from a PHP world where traits were nearly forbidden or used very
sparingly.

> As for it being "back door multi-inheritance", well, Java, Kotlin, and Ru=
st all do essentially that now.  So we're hardly breaking new ground, desig=
n-wise.  If anything, it's playing catch up on data modeling capabilities, =
an area where PHP is still sadly very much lacking.

There's a reason I don't use those languages :p but in all
seriousness, I get what you're saying.