Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128426
Message-ID: <2d2cc2d2-5e62-41da-b697-cd752e48b1f2@varteg.nz>
Date: Fri, 8 Aug 2025 10:49:27 +1200
Precedence: list
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] Protected inheritance hierarchies
To: internals@lists.php.net
References: <c535446a-8108-4f36-b0cb-f116eb69e2ba@app.fastmail.com>
 <1754480697189.440122623.4156562731@yahoo.de>
 <e3900ba3-a305-4991-9093-17d0abc2a46f@jnvsor.net>
 <387eee1d-c46f-460d-965e-c0500255ee57@app.fastmail.com>
Content-Language: en-GB
In-Reply-To: <387eee1d-c46f-460d-965e-c0500255ee57@app.fastmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
From: weedpacket@varteg.nz (Morgan)

On 2025-08-08 10:01, Rob Landers wrote:
> 
> 
> 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—even though the type signatures match perfectly. 
> This is the sort of semantic guarantee that LSP is about, and it is 
> discussed in nearly every reputable textbook and conference talk on OO 
> design. Languages like PHP can’t enforce these contracts, but the / 
> principle/ is what helps prevent subtle design bugs and behavioural 
> “surprises.”
> 
Indeed. Those contracts only become enforceable in the type signature 
when your type system is robust enough to be able to express them. If 
you 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 that the type of the expression C::foo() is written to return is 
of type NonzeroInt (or PositiveInt).

In the absence 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.