Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128420
Content-Type: text/plain; charset=utf-8
Message-ID: <1754572388117.3270901082.2211913261@yahoo.de>
To: rob@bottled.codes
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Protected inheritance hierarchies
Date: Thu, 07 Aug 2025 15:34:30 +0000
In-Reply-To: <a6c7ff82-38dc-456a-887b-e9eeef1168cc@app.fastmail.com>
References: <a6c7ff82-38dc-456a-887b-e9eeef1168cc@app.fastmail.com>
User-Agent: Vivaldi Mail/7.5.3735.58
Content-Transfer-Encoding: quoted-printable
Precedence: list
MIME-Version: 1.0
From: hanskrentel@yahoo.de (Hans Krentel)




On Thursday 07 August 2025 08:46:26 (+02:00), Rob Landers wrote:

>=20
>=20
> 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 =
affect=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 =
it=20
> > also prevents or degrades implementability for me so to say, as =
otherwise 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 in=
 the=20
> > program.
>=20
> See my reply to Jonathan. But you are free to dismiss LSP when needed. =
There are a lot of times when LSP isn=E2=80=99t the right design constraint=
 (which I briefly mention in that email), for example, during larger =
migration/refactors, specialized proxies, caching results, etc., or even =
using sibling classes as friend classes.
>=20
> 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 whatever =
you want with it.=20
>=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).

Thanks a lot for sharing your thoughts that openly and briefly, much =
appreceated.

This all sounds rather sane to me, given PHP is not a design by contract =
language and what makes LSP stand out from formal type theory can get =
easily lost then, especially when applied with force.

I've also studied your other reply to Jonathan.

>=20
> >=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 =
PHP=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 =
someone=20
> > expecting a Mango.
> >=20
> > Thankfully in this example it is all public, but I definitely would =
say=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, nonetheless=
.
> > >=20
> >=20
> > Okay, this is it probably just like above (for me): When $kind would =
be=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 would=
 be=20
> > a test for substitutability, per the PHP runtime guarantees (it =
returns=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 as=
 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 correct=
?
> >=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
>=20
> 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 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.=20

So by protocol, this settled a bit more in harmony. Fine.

And while naming is hard, names are harder: Given that LSP, PHP and the =
(earlier with hooks) class definitions are all human made, and furthermore =
that fruits and vegetables grow from nature, there is or was at least one =
local jurisdiction that would have needed them in their program exactly =
that way: a vegetable declared Fruit. A delicious example of sub-typing =
refreshingly POLArizing.

Thanks Rob.

-- hakre