> 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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
