Hi
On 4/5/24 22:04, Jordan LeDoux wrote:
That is an absurd example. Why would anyone use inheritance for that class
design? If what you are arguing is "if you look at use cases where
composition is clearly the correct choice then inheritance causes
problems", then I'm not sure what the point of the discussion is.
Okay, then please tell me in which use cases inheritance rather than
composition is the right choice? For the "Money" example, I've already
showcased how it would be broken and I can't think of any example where
inheritance would be superior to composition.
Yes, my example is dumb, but nevertheless it showcased that the native
and unchangeable operations would be unsound for child classes with
custom properties, because the operations would not be able to correctly
fill in the custom properties.
And even without custom properties, the behavior would be unsound
because the class name acts as an implicit unit:
$twoMeters = new Distance(2);
$fourSquareMeters = $twoMeters * $twoMeters;
Multiplying two distances does not result in a distance, but rather in
an area. Making it a Distance(4) would be incorrect.
So, which use case would be enabled by allowing inheritance without
being subtly broken by being unable to override the native operations?
As I've said yesterday in Stack Overflow chat: "Operator overloads
through a backdoor are even worse than actual operator overloads".
Best regards
Tim Düsterhus
