Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128416
Feedback-ID: ifab94697:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Thu, 07 Aug 2025 08:46:26 +0200
To: "Hans Krentel" <hanskrentel@yahoo.de>
Cc: internals@lists.php.net
Message-ID: <a6c7ff82-38dc-456a-887b-e9eeef1168cc@app.fastmail.com>
In-Reply-To: <1754480697189.440122623.4156562731@yahoo.de>
References: <c535446a-8108-4f36-b0cb-f116eb69e2ba@app.fastmail.com>
 <1754480697189.440122623.4156562731@yahoo.de>
Subject: Re: [PHP-DEV] Protected inheritance hierarchies
Content-Type: multipart/alternative;
 boundary=430ba8837cce4b93a551d1f69a7c85de
From: rob@bottled.codes ("Rob Landers")

--430ba8837cce4b93a551d1f69a7c85de
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Thu, Aug 7, 2025, at 00:38, Hans Krentel wrote:
>=20
>=20
>=20
> On Wednesday 06 August 2025 13:41:14 (+02:00), Rob Landers wrote:
>=20
> >=20
> >=20
> > On Wed, Aug 6, 2025, at 13:26, Hans Krentel wrote:
> > >=20
> > >=20
> > >=20
> > > On Sunday 03 August 2025 11:30:13 (+02:00), Rob Landers wrote:
> > >=20
> > > > I'm not sure that this is a bug. You can redeclare the same type=
 and=20
> add=20
> > > hooks (or change them), which breaks all assumptions about=20
> > > substitutability.
> > >=20
> > > Rob, maybe you can lecture me a bit: Isn't substitutability on the=20
> public=20
> > > interface / protocol only? What am I not seeing in your example?
> >=20
> > From a child class's perspective, the "public interface" is both=20
> protected + public of the parent. If you change or misuse a parent's=20
> implementation or invariants, it violates LSP, even if it doesn't affe=
ct=20
> external clients immediately.
>=20
> Ah okay, that part is not in my book, this explains to me why in your=20
> example it violates substitutability for you, and with that thinking i=
t=20
> also prevents or degrades implementability for me so to say, as otherw=
ise I=20
> could not make use of visibility in classes - it would take away that =
tool=20
> from me or I would not treat it well, potentially leading to defects i=
n the=20
> program.

See my reply to Jonathan. But you are free to dismiss LSP when needed. T=
here are a lot of times when LSP isn=E2=80=99t the right design constrai=
nt (which I briefly mention in that email), for example, during larger m=
igration/refactors, specialized proxies, caching results, etc., or even =
using sibling classes as friend classes.

PHP doesn=E2=80=99t strictly enforce LSP everywhere. It will get out of =
your way when you need it to. It=E2=80=99s your code, you can do whateve=
r you want with it.=20

Even when I see an LSP violation at work (rare, but it happens), I don=E2=
=80=99t point it out as such, but instead point out why the approach is =
a bad idea (maintainability, principle of least surprise, etc). If they =
do it continuously, then I might have to invest in some coaching for the=
 dev, but mostly, people don=E2=80=99t violate LSP for the more obvious =
reasons, and when they do, they usually have good reasons (see above).

>=20
> >
> > Take for example:
> >=20
> > class Fruit {
> >   public string $kind { get =3D> "fruit" }
> > }
> >=20
> > class Vegetable extends Fruit {
> >   public string $kind { get =3D> "vegetable" }
> > }
> >=20
> > function foo(Fruit $fruit) {}
> >=20
> > foo(new Vegetable); // hmmm
> >=20
> > This is a "soft" violation that only makes sense to us humans, but P=
HP=20
> allows it. It requires us humans to realize we are performing an LSP=20
> violation and refactor the code so that we don't pass a Carrot to some=
one=20
> expecting a Mango.
>=20
> Thankfully in this example it is all public, but I definitely would sa=
y=20
> this is not an LSP violation, just saying.
>=20
> >
> > This can be done through protected means as well (simply replace the=20
> properties above as protected properties used internally), and it won'=
t be=20
> as obvious to consumers outside the class, but still there, nonetheles=
s.
> >=20
>=20
> Okay, this is it probably just like above (for me): When $kind would b=
e=20
> protected, it would not be part of the public protocol, and the=20
> substitutability test with the PHP runtime would still pass for the=20
> foo(Fruit) event with a Vegetable that is a Fruit (extends). That woul=
d be=20
> a test for substitutability, per the PHP runtime guarantees (it return=
s=20
> successfully after sending the message), it does not break the program:
>=20
> >> an object (such as a class) may be replaced by a sub-object (such a=
s a=20
> class that extends the first class) without breaking the program. (WP =
LSP)=20
> <<
>=20
> Still trying to learn more, though.
>=20
> Let me guess: The following hierarchy is not substitutable for you, as=
 we=20
> can still pass Vegetable for Fruit on foo()'s protocol. Is that correc=
t?
>=20
>=20
>      class Fruit {
>          // intentionally left blank
>      }
>=20
>      class Vegetable extends Fruit {
>          // intentionally left blank
>      }
>=20
>      function foo(Fruit $fruit) {}
>=20
>      foo(new Vegetable); // hmmm
>=20
>=20
> -- hakre

I don=E2=80=99t see any reason why this example would violate LSP. There=
 is no discernible difference between the two classes. LSP only says the=
y are substituable in regards to type, and behaviour, and an empty class=
 is probably only a sentinel value, in which case the behaviour is exter=
nal to the type. I might have an issue with saying a vegetable is a frui=
t, but that is a naming issue=E2=80=A6 and naming is hard.=20

=E2=80=94 Rob
--430ba8837cce4b93a551d1f69a7c85de
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 Thu, Aug 7, 2025, at 00:38, 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 Wednesday 06 August 2025 13:41:14 (+02:00)=
, Rob Landers wrote:</div><div><br></div><div>&gt;&nbsp;</div><div>&gt;&=
nbsp;</div><div>&gt; On Wed, Aug 6, 2025, at 13:26, Hans Krentel wrote:<=
/div><div>&gt; &gt;&nbsp;</div><div>&gt; &gt;&nbsp;</div><div>&gt; &gt;&=
nbsp;</div><div>&gt; &gt; On Sunday 03 August 2025 11:30:13 (+02:00), Ro=
b Landers wrote:</div><div>&gt; &gt;&nbsp;</div><div>&gt; &gt; &gt; I'm =
not sure that this is a bug. You can redeclare the same type and&nbsp;</=
div><div>add&nbsp;</div><div>&gt; &gt; hooks (or change them), which bre=
aks all assumptions about&nbsp;</div><div>&gt; &gt; substitutability.</d=
iv><div>&gt; &gt;&nbsp;</div><div>&gt; &gt; Rob, maybe you can lecture m=
e a bit: Isn't substitutability on the&nbsp;</div><div>public&nbsp;</div=
><div>&gt; &gt; interface / protocol only? What am I not seeing in your =
example?</div><div>&gt;&nbsp;</div><div>&gt; From a child class's perspe=
ctive, the "public interface" is both&nbsp;</div><div>protected + public=
 of the parent. If you change or misuse a parent's&nbsp;</div><div>imple=
mentation or invariants, it violates LSP, even if it doesn't affect&nbsp=
;</div><div>external clients immediately.</div><div><br></div><div>Ah ok=
ay, that part is not in my book, this explains to me why in your&nbsp;</=
div><div>example it violates substitutability for you, and with that thi=
nking it&nbsp;</div><div>also prevents or degrades implementability for =
me so to say, as otherwise I&nbsp;</div><div>could not make use of visib=
ility in classes - it would take away that tool&nbsp;</div><div>from me =
or I would not treat it well, potentially leading to defects in the&nbsp=
;</div><div>program.</div></blockquote><div><br></div><div>See my reply =
to Jonathan. But you are free to dismiss LSP when needed. There are a lo=
t of times when LSP isn=E2=80=99t the right design constraint (which I b=
riefly mention in that email), for example, during larger migration/refa=
ctors, specialized proxies, caching results, etc., or even using sibling=
 classes as friend classes.</div><div><br></div><div>PHP doesn=E2=80=99t=
 strictly enforce LSP everywhere. It will get out of your way when you n=
eed it to. It=E2=80=99s your code, you can do whatever you want with it.=
&nbsp;</div><div><br></div><div>Even when I see an LSP violation at work=
 (rare, but it happens), I don=E2=80=99t point it out as such, but inste=
ad point out why the approach is a bad idea (maintainability, principle =
of least surprise, etc). If they do it continuously, then I might have t=
o invest in some coaching for the dev, but mostly, people don=E2=80=99t =
violate LSP for the more obvious reasons, and when they do, they usually=
 have good reasons (see above).</div><div><br></div><blockquote type=3D"=
cite" id=3D"qt" style=3D""><div><br></div><div>&gt;</div><div>&gt; Take =
for example:</div><div>&gt;&nbsp;</div><div>&gt; class Fruit {</div><div=
>&gt;&nbsp;&nbsp; public string $kind { get =3D&gt; "fruit" }</div><div>=
&gt; }</div><div>&gt;&nbsp;</div><div>&gt; class Vegetable extends Fruit=
 {</div><div>&gt;&nbsp;&nbsp; public string $kind { get =3D&gt; "vegetab=
le" }</div><div>&gt; }</div><div>&gt;&nbsp;</div><div>&gt; function foo(=
Fruit $fruit) {}</div><div>&gt;&nbsp;</div><div>&gt; foo(new Vegetable);=
 // hmmm</div><div>&gt;&nbsp;</div><div>&gt; This is a "soft" violation =
that only makes sense to us humans, but PHP&nbsp;</div><div>allows it. I=
t requires us humans to realize we are performing an LSP&nbsp;</div><div=
>violation and refactor the code so that we don't pass a Carrot to someo=
ne&nbsp;</div><div>expecting a Mango.</div><div><br></div><div>Thankfull=
y in this example it is all public, but I definitely would say&nbsp;</di=
v><div>this is not an LSP violation, just saying.</div><div><br></div><d=
iv>&gt;</div><div>&gt; This can be done through protected means as well =
(simply replace the&nbsp;</div><div>properties above as protected proper=
ties used internally), and it won't be&nbsp;</div><div>as obvious to con=
sumers outside the class, but still there, nonetheless.</div><div>&gt;&n=
bsp;</div><div><br></div><div>Okay, this is it probably just like above =
(for me): When $kind would be&nbsp;</div><div>protected, it would not be=
 part of the public protocol, and the&nbsp;</div><div>substitutability t=
est with the PHP runtime would still pass for the&nbsp;</div><div>foo(Fr=
uit) event with a Vegetable that is a Fruit (extends). That would be&nbs=
p;</div><div>a test for substitutability, per the PHP runtime guarantees=
 (it returns&nbsp;</div><div>successfully after sending the message), it=
 does not break the program:</div><div><br></div><div>&gt;&gt; an object=
 (such as a class) may be replaced by a sub-object (such as a&nbsp;</div=
><div>class that extends the first class) without breaking the program. =
(WP LSP)&nbsp;</div><div>&lt;&lt;</div><div><br></div><div>Still trying =
to learn more, though.</div><div><br></div><div>Let me guess: The follow=
ing hierarchy is not substitutable for you, as we&nbsp;</div><div>can st=
ill pass Vegetable for Fruit on foo()'s protocol. Is that correct?</div>=
<div><br></div><div><br></div><div>&nbsp;&nbsp;&nbsp;&nbsp; class Fruit =
{</div><div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // intentio=
nally left blank</div><div>&nbsp;&nbsp;&nbsp;&nbsp; }</div><div><br></di=
v><div>&nbsp;&nbsp;&nbsp;&nbsp; class Vegetable extends Fruit {</div><di=
v>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // intentionally left=
 blank</div><div>&nbsp;&nbsp;&nbsp;&nbsp; }</div><div><br></div><div>&nb=
sp;&nbsp;&nbsp;&nbsp; function foo(Fruit $fruit) {}</div><div><br></div>=
<div>&nbsp;&nbsp;&nbsp;&nbsp; foo(new Vegetable); // hmmm</div><div><br>=
</div><div><br></div><div>-- hakre<br></div></blockquote><div><br></div>=
<div>I don=E2=80=99t see any reason why this example would violate LSP. =
There is no discernible difference between the two classes. LSP only say=
s they are substituable in regards to type, and behaviour, and an empty =
class is probably only a sentinel value, in which case the behaviour is =
external to the type. I might have an issue with saying a vegetable is a=
 fruit, but that is a naming issue=E2=80=A6 and naming is hard.&nbsp;</d=
iv><div><br></div><div id=3D"sig121229152">=E2=80=94 Rob</div></body></h=
tml>
--430ba8837cce4b93a551d1f69a7c85de--