Re: [VOTE] Interface Default Methods
| From: | Robert Landers | Date: | Tue, 11 Jul 2023 17:28:06 +0000 |
| Subject: | Re: [VOTE] Interface Default Methods | ||
| References: | 1 2 3 4 5 6 7 8 9 10 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-120780@lists.php.net to get a copy of this message | ||
> 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.
> As for it being "back door multi-inheritance", well, Java, Kotlin, and Rust all do
> essentially that now. So we're hardly breaking new ground, design-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.