Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:128412 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by lists.php.net (Postfix) with ESMTPS id BDD031A00BC for ; Wed, 6 Aug 2025 22:10:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1754518155; bh=4jZf86g/fcPjoAlzlpYTHytIMSymBHif5W4u2xTjLvs=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=VuGqHHqOOqZEMdit2dpzy3BI5t6G0xbRZ0/WE+TVnyvUeCIY7TeAlcDhpNqYOErOF hPf95p3y3lDeJn6uWTztuSfk5DJm2Rh9+fbNUxpI+vczTULcC3hS5bnuru/Xm2KRQ2 zNjypSFa/PSAjyMovNKs+SXyCjD5ZVOxsGyqLYlkqmCXCH6UD73hXdhp98Dt3FKP+q 0m5XP+mpZTzf15rTwwEHRdzAJem/g6GRqh8d6dkFY/7j79k97SBviVrq/+fuzCMJwP 06tgZOfrppMTAO8HtUh7DFiNwXSGbJwKTRwaM3XD9X3nFbrltCzCbxl8kdxlfGeHwQ fnyJDXMTHlL5Q== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id D797B180048 for ; Wed, 6 Aug 2025 22:09:13 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_MISSING,HTML_MESSAGE, RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS autolearn=no autolearn_force=no version=4.0.1 X-Spam-Virus: No X-Envelope-From: Received: from fhigh-b5-smtp.messagingengine.com (fhigh-b5-smtp.messagingengine.com [202.12.124.156]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Wed, 6 Aug 2025 22:09:03 +0000 (UTC) Received: from phl-compute-05.internal (phl-compute-05.internal [10.202.2.45]) by mailfhigh.stl.internal (Postfix) with ESMTP id A24177A0191; Wed, 6 Aug 2025 18:10:42 -0400 (EDT) Received: from phl-imap-05 ([10.202.2.95]) by phl-compute-05.internal (MEProxy); Wed, 06 Aug 2025 18:10:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bottled.codes; h=cc:cc:content-type:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to; s=fm1; t=1754518241; x= 1754604641; bh=MUIam0iUPEqKihX/iklDLYP2xSMgZPdq42aiJmpDgnk=; b=L ld1Bc6hajYnZWh+h/LJ0nTUZ6+2bn0T7hPmXtzykXrDfAWMNElKUAy5nU3Ah9D8G QOoRgxOG57XuhQSKx8qKyRv3lsNBgxwmuU839i6IqugR+39jNeqnn/2fP2j8JdP/ ep9GkCJe3HuBAbFo6iowwpKsQqjOBFo+UTIWuNxEL1UxjsPRZ0TgRPA9I8DAZDzT y8ak16mFPz9IF3hOmg9FZwGlAVGhoIh8QmZiCRSpAoSk3oSr1eDQrItvROqaOeXt Pjk8i6Pr0FKYc2vsrru/zAXSS6vGeCMKOlD4jQho5HK7aLpQGeo05wAv9jVWEz6D eub5Qfha9oB7Z8DKxxE8A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1754518241; x=1754604641; bh=MUIam0iUPEqKihX/iklDLYP2xSMgZPdq42a iJmpDgnk=; b=jprtouLlEE+422DqiICa1E3ajWpHx8MVVGh6Bn3BPMtD6AOEYwF NMreuv+XxniUWQ3gXvlnIYbp89WUDtU38qcUSCkHz4gw4WETIinWL7QzIO7IGevX dgJJnl+MhPaQEc1VLnzZbQPCjhPxJZzz2eKASTgTJzN//6QvTm0Mr07OMHJrCgFp O32H0Y0epNqnHcLraQdOmEbh3aRyDOnHsmngo6pVHZZbv9FGhqc2dlca2uH6GVm6 NvqI/tQciB/A3rSOEhw3UA4aJSR8h7lX+p5fwA5WYJKZPZ+J8kwGN0y+cteiBHLC 9sY5vRuLtXmDNTBXPeYHtI2vdqCxgJNB88A== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdefgdduudelvddvucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucenucfjughrpefoggffhffvvefkjghfufgtsegrtderre ertdejnecuhfhrohhmpedftfhosgcunfgrnhguvghrshdfuceorhhosgessghothhtlhgv ugdrtghouggvsheqnecuggftrfgrthhtvghrnhepieeuteehvddvfeejhffgieehleehhe dthfefkeejffelgfevvdekudetjeejtddtnecuvehluhhsthgvrhfuihiivgeptdenucfr rghrrghmpehmrghilhhfrhhomheprhhosgessghothhtlhgvugdrtghouggvshdpnhgspg hrtghpthhtohepvddpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepjhhnvhesjhhn vhhsohhrrdhnvghtpdhrtghpthhtohepihhnthgvrhhnrghlsheslhhishhtshdrphhhph drnhgvth X-ME-Proxy: Feedback-ID: ifab94697:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 868B2182007E; Wed, 6 Aug 2025 18:10:40 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface Precedence: list list-help: list-post: List-Id: x-ms-reactions: disallow MIME-Version: 1.0 X-ThreadId: ApgyNlIcRpMw Date: Thu, 07 Aug 2025 00:09:39 +0200 To: "Jonathan Vollebregt" Cc: internals@lists.php.net Message-ID: In-Reply-To: <0266aa5f-73e8-478e-9ef7-9b48fde7e030@jnvsor.net> References: <1754476976305.2190696371.1573579683@yahoo.de> <0266aa5f-73e8-478e-9ef7-9b48fde7e030@jnvsor.net> Subject: Re: [PHP-DEV] Protected inheritance hierarchies Content-Type: multipart/alternative; boundary=ff70252fad6b463fb0ce01dda477854a From: rob@bottled.codes ("Rob Landers") --ff70252fad6b463fb0ce01dda477854a Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Wed, Aug 6, 2025, at 23:20, Jonathan Vollebregt wrote: > On 8/6/25 1:41 PM, Rob Landers wrote: > > 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=20 > > someone expecting a Mango. >=20 > Rob, that's not how types work. The only thing guaranteed by this=20 > definition of $fruit->kind is that it has a getter that returns a=20 > string. "vegetable" is a string. This isn't a violation at all. *"If S is a subtype of T, then objects of type T may be replaced with ob= jects of type S (without altering the desirable properties of the progra= m =E2=80=94 correctness, task performed, etc.)."* Thanks Jonathan, I agree that, from a type-system perspective, `"vegetable"` is a valid s= tring and thus satisfies the declared contract of `Fruit::$kind`. But th= e point of LSP isn=E2=80=99t just about type compatibility =E2=80=94 it = is about the *behavioural* expectations established by the base class. If consumers of `Fruit` rely (even implicitly) on `$kind` always being `= "fruit"` (the property is essentially an instance-level constant here), = then changing that in a subclass makes the code harder to reason about a= nd maintain. The language can=E2=80=99t catch these human-level expectations: that is= up to code reviews and architectural design. My example is intentionall= y =E2=80=9Csoft=E2=80=9D to show how semantic surprises can creep in eve= n when the type checker is happy. That is ultimately why I feel like thi= s issue is a bug. A language can=E2=80=99t check for every possible LSP = violation. It probably shouldn=E2=80=99t as there are diminishing return= s beyond a certain point and there are valid reasons to ignore LSP. > Now if you were able to type specific values in PHP a la psalm/phpstan=20 > and make something like this: >=20 > class Fruit { > public "apple"|"pear" $kind { get =3D> "fruit" } > } >=20 > Well then yeah Vegetable would be a violation, but this would be a=20 > different (and more specific) type than just string. (And this is why=20 > you can't extend enums, it would widen a contract) >=20 > This isn't a "soft" violation that "PHP allows", this is a well define= d=20 > property of every programming language I know of. Right, so if the language was expressive enough (like with literal types= or enums), then changing `$kind` would clearly violate the contract. In= other words, you=E2=80=99re agreeing with me that this would be a viola= tion in a stricter language or type system, so the only difference here = is the *tools* we have available, not the underlying logic.=20 Ultimately, my goal was to illustrate that the principle of LSP is *alwa= ys* present, regardless of whether the language enforces it for you. The= implicit *human* contract is still there, and it is easy to accidentall= y break, especially in languages like PHP. PHP gives us a lot of rope, s= o it is even more important to be aware of the human-level contracts in = our designs. My example was meant to illustrate why relying only on the = language to enforce contracts isn=E2=80=99t always enough. Also, regarding contracts and access: PHP is unusual in that it allows s= ibling classes to access each other=E2=80=99s protected members, which b= lurs boundaries you would see in stricter languages. That is exactly why= I think it is worth talking about the *intent* and *semantics* behind p= rotected, not just what is technically enforced. So, while the type system defines what is *permitted*, it doesn=E2=80=99= t always define what is *sensible. *This is where human reasoning and de= sign principles like LSP come in. =E2=80=94 Rob --ff70252fad6b463fb0ce01dda477854a Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Wed, Aug = 6, 2025, at 23:20, Jonathan Vollebregt wrote:
On 8/6/25 1:41 PM, Rob Landers wrote:
> Take for example:
> 
> class = Fruit {
>    public string $kind { get =3D> "f= ruit" }
> }
> 
> class Veget= able extends Fruit {
>    public string $kind { g= et =3D> "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 performin= g an LSP 
> violation and refactor the code so that we= don't pass a Carrot to 
> someone expecting a Mango.<= /div>

Rob, that's not how types work. The only thing = guaranteed by this 
definition of $fruit->kind is that= it has a getter that returns a 
string. "vegetable" is a= string. This isn't a violation at all.

"If S is a subtype of T, then objects of type T may be replaced= with objects of type S (without altering the desirable properties of th= e program =E2=80=94 correctness, task performed, etc.)."

Thanks Jonathan,

I agree that= , from a type-system perspective, "vegetable" is a valid string and thus satisfies the dec= lared contract of Fruit::= $kind. But the point of LSP isn=E2=80=99t just about type compati= bility =E2=80=94 it is about the behavioural expectations establi= shed by the base class.

If consumers of Fruit rely (even implicit= ly) on $kind alway= s being "fruit"&nb= sp;(the property is essentially an instance-level constant here), then c= hanging that in a subclass makes the code harder to reason about and mai= ntain.

The language can=E2=80=99t catch these h= uman-level expectations: that is up to code reviews and architectural de= sign. My example is intentionally =E2=80=9Csoft=E2=80=9D to show how sem= antic surprises can creep in even when the type checker is happy. That i= s ultimately why I feel like this issue is a bug. A language can=E2=80=99= t check for every possible LSP violation. It probably shouldn=E2=80=99t = as there are diminishing returns beyond a certain point and there are va= lid reasons to ignore LSP.

Now if you were able to type specific values = in PHP a la psalm/phpstan 
and make something like this:<= /div>

class Fruit {
   public "ap= ple"|"pear" $kind { get =3D> "fruit" }
}

Well then yeah Vegetable would be a violation, but this would be = a 
different (and more specific) type than just string. (= And this is why 
you can't extend enums, it would widen a= contract)

This isn't a "soft" violation that "= PHP allows", this is a well defined 
property of every pr= ogramming language I know of.

Righ= t, so if the language was expressive enough (like with literal types or = enums), then changing $ki= nd would clearly violate the contract. In other words, you=E2= =80=99re agreeing with me that this would be a violation in a stricter l= anguage or type system, so the only difference here is the tools = we have available, not the underlying logic. 

Ultimately, my goal was to illustrate that the principle of LSP = is always present, regardless of whether the language enforces it= for you. The implicit human contract is still there, and it= is easy to accidentally break, especially in languages like PHP. PHP gi= ves us a lot of rope, so it is even more important to be aware of the hu= man-level contracts in our designs. My example was meant to illustr= ate why relying only on the language to enforce contracts isn=E2=80=99t = always enough.

Also, regarding contracts a= nd access: PHP is unusual in that it allows sibling classes to access ea= ch other=E2=80=99s protected members, which blurs boundaries you would s= ee in stricter languages. That is exactly why I think it is worth talkin= g about the intent and semantics behind protected, not jus= t what is technically enforced.

So, w= hile the type system defines what is permitted, it doesn=E2=80= =99t always define what is sensible. This is where huma= n reasoning and design principles like LSP come in.

=E2=80=94 Rob
--ff70252fad6b463fb0ce01dda477854a--