Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128413
Content-Type: text/plain; charset=utf-8; format=flowed
Message-ID: <1754480697189.440122623.4156562731@yahoo.de>
To: rob@bottled.codes
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Protected inheritance hierarchies
Date: Wed, 06 Aug 2025 22:38:50 +0000
In-Reply-To: <c535446a-8108-4f36-b0cb-f116eb69e2ba@app.fastmail.com>
References: <c535446a-8108-4f36-b0cb-f116eb69e2ba@app.fastmail.com>
User-Agent: Vivaldi Mail/7.5.3735.58
Content-Transfer-Encoding: 7bit
Precedence: list
MIME-Version: 1.0
From: hanskrentel@yahoo.de (Hans Krentel)




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