Re: Protected inheritance hierarchies

On Fri, Aug 8, 2025, at 15:11, Hans Krentel wrote: > > > > On Friday 08 August 2025 00:49:27 (+02:00), Morgan wrote: > > > On 2025-08-08 10:01, Rob Landers wrote: > > > For example, if |A::foo(): int| promises to always return a non-zero integer, and a > > > subclass overrides |foo()| to only return zero, that violates the contract—even though the type > > > signatures match perfectly. This is the sort of semantic guarantee that LSP is about, and it is > > > discussed in nearly every reputable textbook and conference talk on OO design. Languages like PHP > > > can’t enforce these contracts, but the / principle/ is what helps prevent subtle design bugs and > > > behavioural “surprises.” > > > Indeed. Those contracts only become enforceable in the type signature when your type > > > system is robust enough to be able to express them. If you could declare |A::foo(): NonzeroInt| then > > > the signature could prevent an overriding subclass C from returning zero from that function (while > > > still allowing |C::foo(): PositiveInt|, say); the compiler can verify that the type of the > > > expression C::foo() is written to return is of type NonzeroInt (or PositiveInt). > > > > In the absence of being able to declare such constraints in the type system, one has to > > fall back on other documentation about what behaviour is and isn't acceptable. > > > > That is certainly always useful, especially when it was written down, as it allows to read > both, the fine-print, and between the lines. As you have just quoted Rob's suggestion while > replying to it, allow me the opportunity to highlight a key sentence for me under the pretext of the > earlier quote, and the much appreciated association with documentation of yours to illustrate that: > > > [...] the / principle/ [here, LSP,] is what helps prevent subtle design bugs and > > behavioural “surprises.” > > Documentation, e.g. of pre- and postconditions, loop (in)variants, class invariants, etc, we > can already make use of those corner-stones of the LSP to reason about sub-types, the LSP can > inspire us of what or how we document. And that's what I've learned these days from Rob: > Without reasoning about the LSP. I knew already for what I love Liskov for, but the LSP is so much a > loaded thing in discussions, I had to get a couple of things out of the way first to only understand > Robs reasoning. I came here by the error message, and was looking for what I was missing with it. > > "Oh the types in PHP must do that for us, otherwise my scripts are doomed." > > No. > > The compiler can only handle the type but not the sub-type, because of the halting problem. > > And while my programs can be doomed because of the halting problem (4. Every program is a part > of some other program and rarely fits.), I as human am still able to reason about the correctness of > my program. > > Just my 2 cents > > -- hakre To add to this, here’s one of my favorite examples, ironically, one often used in beginner OOP tutorials: class Rectangle { public int $width; public int $height; } class Square extends Rectangle { public int $width { get => $this->width; set => $this->width = $this->height = $value; } public int $height { get => $this->height; set => $this->height = $this->width = $value; } } This is a classic LSP violation. Square changes Rectangle's contract by linking width/height, removing the independence that Rectangle promised. Meaning when we pass it as a Rectangle and we try to make the Square full screen, it will either be too short length (set width first) or too tall (set height first). In other words, a "Square is a Rectangle" violates LSP, in practice. Yet, this is quite often taught as a beginner example to OOP. Are there cases where you'd want to do this deliberately? Yes, probably. Would you be surprised to find a rectangle extended to the edge of the screen did not extend to the edge of the screen? Yes, probably. In fact, it would probably be filed as a bug. Interestingly, your product people will tell you to "stretch" it (or perform some other transform) making a Square behave like a Rectangle again.. You'd probably end up with something more akin to this: class Rectangle { public int $width; public int $height; public static function asSquare(int $widthAndHeight): static { /* set width and height */ } } Anyway, I digress. Software design is fun... it's a great time to be alive. — Rob