Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128424
Message-ID: <e3900ba3-a305-4991-9093-17d0abc2a46f@jnvsor.net>
Date: Thu, 7 Aug 2025 20:37:18 +0200
Precedence: list
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] Protected inheritance hierarchies
To: Hans Krentel <hanskrentel@yahoo.de>
References: <c535446a-8108-4f36-b0cb-f116eb69e2ba@app.fastmail.com>
 <1754480697189.440122623.4156562731@yahoo.de>
Content-Language: en-US
Cc: internals@lists.php.net
In-Reply-To: <1754480697189.440122623.4156562731@yahoo.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-mijn.host-Spamfilter-Domain: mijn.host
X-mijn.host-Spamfilter-Username: 2a03:5180:7:2:f264:726d:beae:1/112
Authentication-Results: mijn.host; auth=pass smtp.auth=2a03:5180:7:2:f264:726d:beae:1/112@mijn.host
X-mijn.host-Spamfilter-Outgoing-Class: ham
X-mijn.host-Spamfilter-Outgoing-Evidence: Combined (0.28)
X-Recommended-Action: accept
X-Filter-ID: 9kzQTOBWQUFZTohSKvQbgI7ZDo5ubYELi59AwcWUnuWsmSYk1QtGq8DOur+6+9dyegA3Uks29tGA
 X4LiG6Gb9Cu2SmbhJN1U9FKs8X3+Nt2sdENNz0Ob5Mcg8HV4NYhqYDYiFl9huZCsZDn+LUJsU+20
 xtEXt/kSRjovy84YpcAEybI1sOftHmSKUCHCvcq0VvcCA1Qa9BGdQX4vJy9/H5JVRKyFCRrxWkR6
 oZhlSr27jIIUCA+rBO/vL0gUFL32iFKfD1jKgYfH+6S5qDVYoOmeRt7qHd5fQGuXWoplKlc1R6Pa
 oqS3DNVMIxswrKXjmTmYf9felIf8Q0lvYJANy1im26jqdSLearSSTVIJyNKROUzReCS8EpKh0It9
 L25JS816nuiE0t5pG6MLXGczofgXbS3qE61+OyR3Gc3nPUAkegH8AGg21BffYc5vZTkUwH34Upjg
 oeqgIDrFIrvO7+0aRbZk85NvEefkoSA+zXcvJuwl5fjKNe9yZBtrjaM9xEJYeWfJSk21pH43sUC7
 1lktQNYXmRiLO5LZeh8LNb/h5rz7DLGg45GiUflDl8Pj2akSwD/pSEmvxWvR3fDzkLJ2UFyRsw29
 tR4/IrseQC/4hO6RFjmINtYHMzaX33L/tiUbuNooEA7vZpGZDzmDZgIrBW1POd3o/7DSQTTj6s9Y
 TPEQFtK83f11FvBEWMEBI7CwI3bS1vgQJo6x+DddptN1fsCPigxM7SJUfln/JfEUkbqD/uIH8xTd
 WUhclVOYEsPvSCTlfM5Y80pDXX9tTiwVgrK/7QwfJv1RRuxwcLuEvz2n1rNwe171zTv0+4jIReiC
 tmFn0ADLIXPKDNedc4zsBDjH9DHvNgD+hPJh6YgIBGH410FLO/EAYb3GPEo8iJqDgs6RAwpb87Vf
 b9Iz0TXdlYAq6UjIxP1xMwYPoGLExzWxWyPSMeXzqo8Q4inxctgzcDoFd+96Xw4QUNtTneOQTU3U
 jDF2OBsHCKzGTYiz8VlyFBlXkWhIz+XlKI6Osb3p8YGPqdx9YesYZ2kEPVt51XbultM4HiyNgPp2
 q0tR4oPERYWp9aw199O5emhHusUwx3A/VWW7RJdlrDgzR+tjKjwx6m43vUn7qqn63AQBupGDLZdC
 L3LKbw2iVCYOWXejn1PsqQY/5pHqdKO0/TEvuGslKTrRIXcXpFg5ivY=
X-Report-Abuse-To: spam@filter101.mijn.host
X-Complaints-To: abuse@filter101.mijn.host
From: jnv@jnvsor.net (Jonathan Vollebregt)

On 8/7/25 12:38 AM, Hans Krentel wrote:
>  > > 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.

Don't believe everything you read on the internet.

If you weren't allowed to change a parent's implementation, then you 
wouldn't be permitted to override methods at all, at which point 
inheritance is pointless.

It's funny that he's starting to talk about invariants here. Seems he 
doesn't realize every example he's given so far is covariant (Besides 
the one at the beginning of the thread where he confused static and 
non-static properties)

He's trying to argue that LSP is about implementation when it's not. 
This is an interface with a function signature:

interface I {
     function f(): string;
}

See a fruit anywhere? Me neither. That's because there isn't one. It's 
not part of the signature. It's not part of the interface. It's not part 
of the definition. It's not part of the contract.

This is a class with _the same function signature_:

class C {
     function f(): string {
         return "fruit";
     }
}

In fact, this class could implement that interface without any problems, 
because the signature is identical. The types are identical. There is no 
LSP violation. There is also no contract that implies C::f() returns 
"fruit".

If you made that assumption I'd call it a lack of error handling from 
someone who only considered the happy path. Static analysis tools exist 
to stop you from making these mistakes.

Once more, just to drive the point home. This is an interface with a 
function signature:

interface I {
     public int $p { get; }
}

This is a class with the same function signature (And one more for good 
measure, because I::$p is covariant!):

class C {
     public int $p;
}

In fact, this class could implement that interface without any problems, 
because the signature is identical. The types are identical. There is no 
LSP violation. There is no contract that implies that getting C->p will 
return a certain value, other than that the value will be an int.

---

Back to the original issue: I'm going to open a github issue on this 
since it's clearly a bug and I don't see fixing it breaking any existing 
code.