Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128436
Feedback-ID: ifab94697:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Fri, 08 Aug 2025 16:03:56 +0200
To: "Hans Krentel" <hanskrentel@yahoo.de>, weedpacket@varteg.nz,
 internals@lists.php.net
Message-ID: <64e8ee39-15ed-4f70-9c59-66f880db528b@app.fastmail.com>
In-Reply-To: <1754655377927.1104458686.3594147701@yahoo.de>
References: <2d2cc2d2-5e62-41da-b697-cd752e48b1f2@varteg.nz>
 <1754655377927.1104458686.3594147701@yahoo.de>
Subject: Re: [PHP-DEV] Protected inheritance hierarchies
Content-Type: multipart/alternative;
 boundary=fa559c3bdb7042f78dd5d5068c4d9a79
From: rob@bottled.codes ("Rob Landers")

--fa559c3bdb7042f78dd5d5068c4d9a79
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Fri, Aug 8, 2025, at 15:11, Hans Krentel wrote:
>=20
>=20
>=20
> On Friday 08 August 2025 00:49:27 (+02:00), Morgan wrote:
>=20
> > On 2025-08-08 10:01, Rob Landers wrote:
> > > For example, if |A::foo(): int| promises to always return a non-ze=
ro integer, and a subclass overrides |foo()| to only return zero, that v=
iolates the contract=E2=80=94even though the type signatures match perfe=
ctly. This is the sort of semantic guarantee that LSP is about, and it i=
s discussed in nearly every reputable textbook and conference talk on OO=
 design. Languages like PHP can=E2=80=99t enforce these contracts, but t=
he / principle/ is what helps prevent subtle design bugs and behavioural=
 =E2=80=9Csurprises.=E2=80=9D
> > > Indeed. Those contracts only become enforceable in the type signat=
ure when your type system is robust enough to be able to express them. I=
f you could declare |A::foo(): NonzeroInt| then the signature could prev=
ent an overriding subclass C from returning zero from that function (whi=
le still allowing |C::foo(): PositiveInt|, say); the compiler can verify=
 that the type of the expression C::foo() is written to return is of typ=
e NonzeroInt (or PositiveInt).
> >=20
> > In the absence of being able to declare such constraints in the type=
 system, one has to fall back on other documentation about what behaviou=
r is and isn't acceptable.
> >=20
>=20
> 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 op=
portunity to highlight a key sentence for me under the pretext of the ea=
rlier quote, and the much appreciated association with documentation of =
yours to illustrate that:
>=20
> >  [...] the / principle/ [here, LSP,] is what helps prevent subtle de=
sign bugs and behavioural =E2=80=9Csurprises.=E2=80=9D
>=20
> Documentation, e.g. of pre- and postconditions, loop (in)variants, cla=
ss invariants, etc, we can already make use of those corner-stones of th=
e LSP to reason about sub-types, the LSP can inspire us of what or how w=
e document. And that's what I've learned these days from Rob: Without re=
asoning about the LSP. I knew already for what I love Liskov for, but th=
e 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 h=
ere by the error message, and was looking for what I was missing with it.
>=20
> "Oh the types in PHP must do that for us, otherwise my scripts are doo=
med."
>=20
> No.
>=20
> The compiler can only handle the type but not the sub-type, because of=
 the halting problem.
>=20
> 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 h=
uman am still able to reason about the correctness of my program.
>=20
> Just my 2 cents
>=20
> -- hakre

To add to this, here=E2=80=99s 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 =3D> $this->width; set =3D> $this->width =3D $=
this->height =3D $value; }
  public int $height { get =3D> $this->height; set =3D> $this->height =3D=
 $this->width =3D $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 fu=
ll screen, it will either be too short length (set width first) or too t=
all (set height first). In other words, a "Square is a Rectangle" violat=
es LSP, in practice. Yet, this is quite often taught as a beginner examp=
le 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 per=
form 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 ali=
ve.

=E2=80=94 Rob
--fa559c3bdb7042f78dd5d5068c4d9a79
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title></head><body><div><br></div><d=
iv><br></div><div>On Fri, Aug 8, 2025, at 15:11, Hans Krentel wrote:</di=
v><blockquote type=3D"cite" id=3D"qt" style=3D""><div><br></div><div><br=
></div><div><br></div><div>On Friday 08 August 2025 00:49:27 (+02:00), M=
organ wrote:</div><div><br></div><div>&gt; On 2025-08-08 10:01, Rob Land=
ers wrote:</div><div>&gt; &gt; 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=E2=80=94even though the ty=
pe signatures match perfectly. This is the sort of semantic guarantee th=
at LSP is about, and it is discussed in nearly every reputable textbook =
and conference talk on OO design. Languages like PHP can=E2=80=99t enfor=
ce these contracts, but the / principle/ is what helps prevent subtle de=
sign bugs and behavioural =E2=80=9Csurprises.=E2=80=9D</div><div>&gt; &g=
t; Indeed. Those contracts only become enforceable in the type signature=
 when your type system is robust enough to be able to express them. If y=
ou 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 th=
at the type of the expression C::foo() is written to return is of type N=
onzeroInt (or PositiveInt).</div><div>&gt;&nbsp;</div><div>&gt; In the a=
bsence 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.</div><div>&gt;&nbsp;</div><div><br></div><div>That is cer=
tainly 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 qu=
oted 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 illu=
strate that:</div><div><br></div><div>&gt;&nbsp; [...] the / principle/ =
[here, LSP,] is what helps prevent subtle design bugs and behavioural =E2=
=80=9Csurprises.=E2=80=9D</div><div><br></div><div>Documentation, e.g. o=
f pre- and postconditions, loop (in)variants, class invariants, etc, we =
can already make use of those corner-stones of the LSP to reason about s=
ub-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 load=
ed 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 messag=
e, and was looking for what I was missing with it.</div><div><br></div><=
div>"Oh the types in PHP must do that for us, otherwise my scripts are d=
oomed."</div><div><br></div><div>No.</div><div><br></div><div>The compil=
er can only handle the type but not the sub-type, because of the halting=
 problem.</div><div><br></div><div>And while my programs can be doomed b=
ecause 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.</div><div><br></div><div>Just my 2 cents</div=
><div><br></div><div>-- hakre</div></blockquote><div><br></div><div>To a=
dd to this, here=E2=80=99s one of my favorite examples, ironically, one =
often used in beginner OOP tutorials:</div><div><br></div><div>class Rec=
tangle {</div><div>&nbsp; public int $width;</div><div>&nbsp; public int=
 $height;</div><div>}</div><div><br></div><div>class Square extends Rect=
angle {</div><div>&nbsp; public int $width { get =3D&gt; $this-&gt;width=
; set =3D&gt; $this-&gt;width =3D $this-&gt;height =3D $value; }</div><d=
iv>&nbsp; public int $height { get =3D&gt; $this-&gt;height; set =3D&gt;=
 $this-&gt;height =3D $this-&gt;width =3D $value; }</div><div>}</div><di=
v><br></div><div>This is a classic LSP violation. Square changes Rectang=
le's contract by linking width/height, removing the independence that Re=
ctangle promised. Meaning when we pass it as a Rectangle and we try to m=
ake the Square full screen, it will either be too short length (set widt=
h 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.</div><div><br></div><div>Are there cases whe=
re you'd want to do this deliberately? Yes, probably. Would you be surpr=
ised to find a rectangle extended to the edge of the screen did not exte=
nd to the edge of the screen? Yes, probably. In fact, it would probably =
be filed as a bug.</div><div><br></div><div>Interestingly, your product =
people will tell you to "stretch" it (or perform some other transform) m=
aking a Square behave like a Rectangle again. You'd probably end up with=
 something more akin to this:</div><div><br></div><div>class Rectangle {=
</div><div>&nbsp; public int $width;</div><div>&nbsp; public int $height=
;</div><div>&nbsp; public static function asSquare(int $widthAndHeight):=
 static { /* set width and height */ }</div><div>}<br></div><div><br></d=
iv><div>Anyway, I digress. Software design is fun... it's a great time t=
o be alive.</div><div><br></div><div id=3D"sig121229152">=E2=80=94 Rob</=
div></body></html>
--fa559c3bdb7042f78dd5d5068c4d9a79--