Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120779
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-531-gfdfa13a06d-fm-20230703.001-gfdfa13a0
Mime-Version: 1.0
Message-ID: <66e67efa-1f41-4971-b070-7785f99ab286@app.fastmail.com>
In-Reply-To: 
 <CAPzBOBPGihd+HNFDaYAO9x+LgGHtZ8r_UDBxS=+jcSHq=DCBPQ@mail.gmail.com>
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>
Date: Tue, 11 Jul 2023 16:47:57 +0000
To: "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: larry@garfieldtech.com ("Larry Garfield")

On Tue, Jul 11, 2023, at 3:16 PM, Robert Landers wrote:
> On Tue, Jul 11, 2023 at 4:36=E2=80=AFPM Larry Garfield <larry@garfield=
tech.com> wrote:
>> You have to check your vendor folder for an interface, or trait, or a=
bstract class.  That doesn't change anything.
>>
>> As noted, now consider a Baz interface.  For interface-and-trait, you=
 add 2 more definitions.  For interface-with-defaults, you add 1.  For a=
bstract classes, you need to add 4: BazBase, FooBazBase, BarBazBase, and=
 FooBarBazBase.
>
> I guess I don't understand what the interface is solving if you're
> creating an interface _and_ a trait, why not just create the trait? It
> sounds like you're coupling your interface to a specific
> implementation and trying to get multi-inheritance out of PHP. This
> seems like a design issue, and this RFC seems like a back-way to
> multiple inheritance. Why not just allow multiple inheritance?
>
>> And that's assuming you're even in control of the base classes; you m=
ay not even be able to create all those combinations without lots of cop=
y-pasta.
>>
>> Abstract classes are basically vestigial since PHP 5.4, and have no u=
se cases:
>
> As a user of abstract classes since the early days of C++, I disagree.
>
> I'd love to see a concrete example, but to me, this just seems like a
> bandaid on an architectural smell.

Real code I wrote a week ago (specifically, for a series of events in a =
domain model):

https://gist.github.com/Crell/f5929e2ee44decd4e9353c41874f26c8

Two different interfaces, that I want to be able to check against, but t=
heir implementations are trivial.  One of them is used in 2 classes, the=
 other in 3.  A base class simply wouldn't work, both because it's seman=
tically incorrect (these events are not all "special cases of" some comm=
on definition, that's not the data model), and because then I couldn't h=
ave the class that uses only one of them.  Traits, for now, are the best=
 solution, and this is an approach that gets taken a lot.

Interface default methods saves a file, and lets us merge the traits int=
o the interfaces.  That's basically it.  And that's helpful.

As for it being "back door multi-inheritance", well, Java, Kotlin, and R=
ust all do essentially that now.  So we're hardly breaking new ground, d=
esign-wise.  If anything, it's playing catch up on data modeling capabil=
ities, an area where PHP is still sadly very much lacking.

--Larry Garfield