Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120781
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-531-gfdfa13a06d-fm-20230703.001-gfdfa13a0
Mime-Version: 1.0
Message-ID: <bea26b5e-5d50-42f5-9c6a-809c10076493@app.fastmail.com>
In-Reply-To: 
 <CAPzBOBOr98CrQZpL0yDVeAVrCwx9csWQFfBtjmkvrX9b+E8Khg@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>
 <66e67efa-1f41-4971-b070-7785f99ab286@app.fastmail.com>
 <CAPzBOBOr98CrQZpL0yDVeAVrCwx9csWQFfBtjmkvrX9b+E8Khg@mail.gmail.com>
Date: Tue, 11 Jul 2023 17:42:26 +0000
To: "Robert Landers" <landers.robert@gmail.com>
Cc: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: Re: [PHP-DEV] [VOTE] Interface Default Methods
From: larry@garfieldtech.com ("Larry Garfield")

On Tue, Jul 11, 2023, at 5:28 PM, Robert Landers wrote:
>> 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 their 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 semantically incorrect (these events are not all "special cases of" some common definition, 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 this 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.

Traits are a surgical tool with a narrow set of uses, and systems that over-use them cause problems.  (You know which framework you are...)  But this is one of their main valid uses.

In context, the classes are not siblings, and it would be incorrect for them to extent from a base class.  They just both happen to implement the same *interface*, but that the same as having the same "is a special case of" relationship with a base class.

Having a common base class instead would, as noted before, mean as soon as I added a third "carries" option, I'd have to add four more base classes to cover all combinations.  It quickly gets absurd, and those base classes have no valid type usage; they're purely there as an alternative to copy-paste.

Using inheritance as an alternative to copy-paste is the wrong way(tm) to do it.  Both inheritance and copy-paste.  Freshman CS classes still love to talk about inheritance as a great thing for code reuse but... it's really not, and many of the 21st century languages have been drifting away from that.

Traits/default-method-interfaces are a better alternative that doesn't conflate "copy-paste avoidance" with "is a special case of."  Honestly, I almost never use class inheritance in my greenfield code these days.  

--Larry Garfield