On Wednesday 06 August 2025 13:41:14 (+02:00), Rob Landers wrote:
> > > On Wed, Aug 6, 2025, at 13:26, Hans Krentel wrote:
> > > > > > > > On Sunday 03 August 2025 11:30:13 (+02:00), Rob Landers wrote:
> > > > > I'm not sure that this is a bug. You can redeclare the same type and add > > hooks (or change them), which breaks all assumptions about > > substitutability.
> > > > Rob, maybe you can lecture me a bit: Isn't substitutability on the public > > interface / protocol only? What am I not seeing in your example?
> > From a child class's perspective, the "public interface" is both protected + public of the parent. If you change or misuse a parent's implementation or invariants, it violates LSP, even if it doesn't affect external clients immediately.
Ah okay, that part is not in my book, this explains to me why in your example it violates substitutability for you, and with that thinking it also prevents or degrades implementability for me so to say, as otherwise I could not make use of visibility in classes - it would take away that tool from me or I would not treat it well, potentially leading to defects in the program.
>
> Take for example:
> > class Fruit {
> public string $kind { get => "fruit" }
> }
> > class Vegetable extends Fruit {
> public string $kind { get => "vegetable" }
> }
> > function foo(Fruit $fruit) {}
> > foo(new Vegetable); // hmmm
> > This is a "soft" violation that only makes sense to us humans, but PHP allows it. It requires us humans to realize we are performing an LSP violation and refactor the code so that we don't pass a Carrot to someone expecting a Mango.
Thankfully in this example it is all public, but I definitely would say this is not an LSP violation, just saying.
>
> This can be done through protected means as well (simply replace the properties above as protected properties used internally), and it won't be as obvious to consumers outside the class, but still there, nonetheless.
>
Okay, this is it probably just like above (for me): When $kind would be protected, it would not be part of the public protocol, and the substitutability test with the PHP runtime would still pass for the foo(Fruit) event with a Vegetable that is a Fruit (extends). That would be a test for substitutability, per the PHP runtime guarantees (it returns successfully after sending the message), it does not break the program:
>> an object (such as a class) may be replaced by a sub-object (such as a class that extends the first class) without breaking the program. (WP LSP) <<
Still trying to learn more, though.
Let me guess: The following hierarchy is not substitutable for you, as we can still pass Vegetable for Fruit on foo()'s protocol. Is that correct?
class Fruit {
// intentionally left blank
}
class Vegetable extends Fruit {
// intentionally left blank
}
function foo(Fruit $fruit) {}
foo(new Vegetable); // hmmm
-- hakre