Re: [VOTE] Interface Default Methods

From: 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.

« previous php.internals (#120780) next »