Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:128378 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 8B8331A00BC for ; Sat, 2 Aug 2025 21:18:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1754169437; bh=lVHDJR+xEH4nrj/1S53e1/QmfUvC5R4zRmgE+x8bZwY=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=L+3jR3WjSv6/8vxHFvix6IoYqXO6xZNesbwRN9IpR7TDWAhk5ZLDvbEoajJ8h8xpJ pGzEqqwHBxR4yyeAODFiGKKpYwHR46TpRu1QmVznn1OO85E8u2erce55EwfHt6ygex UUJugOkE4tKhLKuhvobFG/PvZWu0rJ2ooN0S7z6o0oie9BR+gK0e8JbdmDlplRzV89 vdDcWS7QbWOKwwfpNAjs5SX0EJXBqjosqBVXMpbB1CSuAeNuThLJh7tD/iyjpiek2I gHGF4s5j6lfDwrOL9ZrQvhoPFcqVTqNLvEUKsiM8yHKDJp87kx18gBLoK5rH34ZlOV uy/qj74TpFolQ== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id CCA2C180039 for ; Sat, 2 Aug 2025 21:17:15 +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: Error (Cannot connect to unix socket '/var/run/clamav/clamd.ctl': connect: Connection refused) X-Envelope-From: Received: from fhigh-b2-smtp.messagingengine.com (fhigh-b2-smtp.messagingengine.com [202.12.124.153]) (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 ; Sat, 2 Aug 2025 21:17:15 +0000 (UTC) Received: from phl-compute-05.internal (phl-compute-05.phl.internal [10.202.2.45]) by mailfhigh.stl.internal (Postfix) with ESMTP id 115827A0207; Sat, 2 Aug 2025 17:18:56 -0400 (EDT) Received: from phl-imap-05 ([10.202.2.95]) by phl-compute-05.internal (MEProxy); Sat, 02 Aug 2025 17:18:56 -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=1754169535; x= 1754255935; bh=lVHDJR+xEH4nrj/1S53e1/QmfUvC5R4zRmgE+x8bZwY=; b=P PSL2fBjTkiymbC91zDrdFDMzbuhHg0y5QNRgzEj9PSNnmWQbJ0Hf0tGaqo9polvT VNZFc8Y2SiCEUMWphv0rAk56zZRZDZ5mMEeXlaSUPlWpuxz4Gw1S6e0F6sFws3Yp zg5ymHfgqTKI5vY7qyibi7wk2zeJKEJAn1FgejOtGh87q2+SjsrCDrHCobuqyhW8 E3bjJY3gr2dwjE2NMv27v3YSfdnEJPlLFZA2D53JrNI2xEt0vavz/xOM6LTMfqdb 1gyaQrcLbyS7Cu2mq51B7BTpyX22QRe4SvwUpqUNwFFEdNp90h0yasR+/qZhD/BG 1Iw9MuLmS2F9XCjTIIueQ== 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= 1754169535; x=1754255935; bh=lVHDJR+xEH4nrj/1S53e1/QmfUvC5R4zRmg E+x8bZwY=; b=J7R37BwFKSTQsxv3xNGPT14pc/pMJt38BO6Tto03zvBSW437cP1 CVlRroi/0Xgx+mdX0KGhFhXObCT2Fv9an5UXL6uRUC4FOztr05cOCsoT8wZIoegf FxdFXg5UxwRFRPhNDq6amzI6jzDRbS35laCHgSG6kKdKT2cZQ4O0QOVUlkvA9Swi gS217QULipWflcwTF+fnNbYEzpW1SUUYwzZaT/aWwVKPnppQ2ydDDLRIV014Cep9 0Wa6v0K5/dz2BcmmUJWfWztFi+PUam13IA8h6cSDRkEhIZsIYuoHrWy3KQeCzQ/n QTkwA+1XoRenpdLLrVk3JAmAxKsrMm/4U/w== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdefgddutdejieefucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnegouf hushhpvggtthffohhmrghinhculdegledmnecujfgurhepofggfffhvfevkfgjfhfutges rgdtreerredtjeenucfhrhhomhepfdftohgsucfnrghnuggvrhhsfdcuoehrohgssegsoh htthhlvggurdgtohguvghsqeenucggtffrrghtthgvrhhnpeetleejuddugeehjeeuvedu feelffetjeeuteelueffgeeitdejieeiheegheehheenucffohhmrghinhepfehvgehlrd horhhgpdhgihhthhhusgdrtghomhdpphhrohhgrhgrmhhiiidrtghomhdpphhhphdrnhgv thdpgidrtghomhenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehrohgssegsohhtthhlvggurdgtohguvghspdhnsggprhgtphhtthhopeefpdhm ohguvgepshhmthhpohhuthdprhgtphhtthhopegurhgvrghlvggtshesghhmrghilhdrtg homhdprhgtphhtthhopehuuggrlhhtshhovhdrvhgrlhgvnhhtihhnsehgmhgrihhlrdgt ohhmpdhrtghpthhtohepihhnthgvrhhnrghlsheslhhishhtshdrphhhphdrnhgvth X-ME-Proxy: Feedback-ID: ifab94697:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 7120F1820074; Sat, 2 Aug 2025 17:18:55 -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: Sat, 02 Aug 2025 23:18:33 +0200 To: "Valentin Udaltsov" Cc: =?UTF-8?Q?Alexandru_P=C4=83tr=C4=83nescu?= , "PHP internals" Message-ID: <30dabc72-a98a-4758-a84f-4defcc959e25@app.fastmail.com> In-Reply-To: References: <2d516e15-2fc7-4ac4-b9c2-7146ac01cfb1@app.fastmail.com> <8c60c0b8-8826-49a4-80ba-973ff833fff7@app.fastmail.com> <900d2936-6afd-4eed-b08a-1540d124273a@app.fastmail.com> Subject: Re: [PHP-DEV] Protected inheritance hierarchies Content-Type: multipart/alternative; boundary=8c1486ba3dd645488ad82cb5dc27995b From: rob@bottled.codes ("Rob Landers") --8c1486ba3dd645488ad82cb5dc27995b Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Sat, Aug 2, 2025, at 22:18, Valentin Udaltsov wrote: > On Sat, Aug 2, 2025, at 22:17, Rob Landers wrote: >> __ >> On Sat, Aug 2, 2025, at 19:04, Alexandru P=C4=83tr=C4=83nescu wrote: >>>=20 >>>=20 >>> On Sat, Aug 2, 2025, 17:10 Rob Landers wrote: >>>> __ >>>>=20 >>>>=20 >>>> On Sat, Aug 2, 2025, at 16:04, Alexandru P=C4=83tr=C4=83nescu wrote: >>>>>=20 >>>>>=20 >>>>> On Sat, Aug 2, 2025 at 12:10=E2=80=AFPM Rob Landers wrote: >>>>>> __ >>>>>> On Tue, Jul 29, 2025, at 20:11, Jonathan Vollebregt wrote: >>>>>>> I came across this edge case today: >>>>>>>=20 >>>>>>> https://3v4l.org/R3Q8D >>>>>>>=20 >>>>>>> Both psalm and phpstan think this code is A-OK (Once you add the=20 >>>>>>> requisite type hints) but it causes fatal errors way back to PHP= 5.0.0 >>>>>>>=20 >>>>>>> ...... >>>>>>=20 >>>>>> It's not an edge case, in C2, you redefine a protected variable w= ith the same name and shadowed the original $v. That $v is different tha= n C's $v. It's easiest to see this with static access: https://3v4l.org/= 0SRWb#v8.4.10 >>>>>>=20 >>>>>> However, I don't know of any way to unshadow a property from $thi= s to access the ancestor's value (other than using private access), but = it exists and takes up memory; just accessing it is the hard part. >>>>>>=20 >>>>>> =E2=80=94 Rob >>>>>=20 >>>>>=20 >>>>> Hi Rob, >>>>>=20 >>>>> I'm pretty sure that there is no shadowing happening in the exampl= e. >>>>> When the child instance is created, there is just one slot for the= property, as the child one replaces the parent one. >>>>> So basically the child property overrides the parent property rath= er than shadowing it. >>>>>=20 >>>>> True shadowing (two slots) only occurs when the parent property is= declared private. >>>>>=20 >>>>> It's just that when redefining, it stores the declaring class, and= so there is this sibling class access issue. >>>>>=20 >>>>> I'm wondering now if the access shouldn't be relaxed, in case we h= ave the parent class that initially defined the property. >>>>>=20 >>>>> Of course, we should focus on non-static properties, as static one= s are different things, and there is some shadowing there. >>>>>=20 >>>>> --=20 >>>>> Alex >>>>=20 >>>> Hi Alex, >>>>=20 >>>> I=E2=80=99m not sure what you mean? https://3v4l.org/WKILh#v8.4.10 >>>>=20 >>>> There is clearly shadowing going on. >>>>=20 >>>>=20 >>>=20 >>> Hi Rob, >>>=20 >>> As I said, let's leave aside the static case, as the question from J= onathan was not about that. >>>=20 >>> Given the class P that defines a protected property with value 1, >>> and a class C that extends P and re-defines the protected property w= ith the value 2, >>> please show me an example where you could get from an instance of cl= ass C the value 1 of the parent class property that you think it's shado= wed. >>> Bonus point, if you manage that, you could also set it to something = else, and so have a hidden storage for any object of class C that is not= really visible normally. >>>=20 >>> As far as I know, there is no way to achieve that, and the reason is= because at runtime the objects have a single slot for the protected pro= perty; the child class property overrides the parent class property when= redeclared, and does not shadow it. >>> But please prove me wrong. >>>=20 >>>=20 >>> Thanks, >>> Alex >>>=20 >>=20 >> I mentioned in my first reply, there is no way to get an instance-lev= el property unshadowed. It is there though (according to inheritance.c, = if I=E2=80=99m reading it right, it is still accessible, just not from u= ser-land). >>=20 >> In any case, there are lots of interesting footguns with properties a= nd inheritance: Problem with abstract nested object =C2=B7 Issue #47 =C2= =B7 Crell/Serde .=20 >>=20 >>> Could it be considered a bug that my first example produces a fatal=20 >>> error instead of trying to access the shadowed parent property that = it=20 >>> has access to and is typed to use? >>=20 >> Other languages (such as C#, Java, etc: https://www.programiz.com/onl= ine-compiler/0ud6UO24mHOTU) don=E2=80=99t allow you to access protected = properties/methods on sibling classes. This is because "protected" is us= ually used in the context of inheritance; access is usually restricted t= o "myself" or "children" and a sibling is neither of those. If there is = a bug, the bug is that you can access a sibling=E2=80=99s protected prop= erties, at all. >>=20 >> =E2=80=94 Rob >=20 > > If there is a bug, the bug is that you can access a sibling=E2=80=99= s protected properties, at all. >=20 > In 2006 the absence of this feature was fixed as a bug and meged in PH= P 5.2: https://bugs.php.net/bug.php?id=3D37632 > In 2020 Nikita Popov agreed that this is expected: https://x.com/nikit= a_ppv/status/1261633126687805440 >=20 > So one way is to explicitly mention this feature in the Visibility doc= s and fix t= he redeclaration issue to make things consistent. >=20 > The other way is to deprecate sibling relations. >=20 > -- > Valentin I don=E2=80=99t think the redeclaration is a bug though, as is mentioned= in the linked bug report about properties: https://bugs.php.net/bug.php= ?id=3D37212, it is pretty clear to me that people expect a redeclaration= would be a fatal error, but not accessing a property declared in a shar= ed parent scope (emphasis mine): > The property *is not being redeclared in C*, though. *It is still a pr= operty of A, structure-wise.* A method declared and called in the same w= ay as the property does not cause any error. This has been the case for years, so I don=E2=80=99t think it is a bug. = I was only saying that if there is a bug, the bug would be that you can = access another class=E2=80=99s protected properties that aren=E2=80=99t = a parent or sibling. I didn=E2=80=99t really go into why, but IMHO, it b= reaks LSP, since it allows sibling classes to depend on each other=E2=80= =99s internals, breaking substitutability (particularly in regards to ho= oks). =E2=80=94 Rob --8c1486ba3dd645488ad82cb5dc27995b Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


On Sat, Aug 2, 2025, at 22:18, Valentin Udaltsov wrote= :
<= div dir=3D"ltr">On Sat, Aug 2, 2025, at 22:17, Rob Landers <rob@bottl= ed.codes> wrote:

On Sat, Aug 2, 2025, at 19:04, A= lexandru P=C4=83tr=C4=83nescu wrote:


<= /div>
On Sat, Aug 2, 2025, 17:10 Rob L= anders <rob@bottled.codes> wrote:



<= /div>
On Sat, Aug 2, 2025, at 16:04, Alexandru P=C4=83tr=C4=83nescu = wrote:


On Sat, Aug 2, 2025 at 12:10=E2=80=AFPM= Rob Landers <rob@bottled.codes> wrote:

On Tue, Jul 29= , 2025, at 20:11, Jonathan Vollebregt wrote:
I came across this edge case today:


Both psalm a= nd phpstan think this code is A-OK (Once you add the 
req= uisite type hints) but it causes fatal errors way back to PHP 5.0.0

...<snip>...

It's not an edge case, in C2, you redefine a protected variable wi= th the same name and shadowed the original $v. That $v is different than= C's $v. It's easiest to see this with static access: https= ://3v4l.org/0SRWb#v8.4.10

However, I don't = know of any way to unshadow a property from $this to access the ancestor= 's value (other than using private access), but it exists and takes up m= emory; just accessing it is the hard part.

=E2=80=94 Rob


Hi Rob,

I'm pretty sure that th= ere is no shadowing happening in the example.
When the ch= ild instance is created, there is just one slot for the property, as the= child one replaces the parent one.
So basically the child pro= perty overrides the parent property=20=0A=0Arather than shadowing it.

True shadowing (two slots) only occurs when= the parent property is declared private.

It's = just that when redefining, it stores the declaring class, and so there i= s this sibling class access issue.

I'm wonderin= g now if the access shouldn't be relaxed, in case we have the parent cla= ss that initially defined the property.

Of cour= se, we should focus on non-static properties, as static ones are differe= nt things, and there is some shadowing there.

-= - 
Alex

Hi Alex,

I=E2=80=99m not sure what you mean?&n= bsp;https://3v4l.org/WKILh#v8.4.10

= There is clearly shadowing going on.



Hi Ro= b,

As I said, let's l= eave aside the static case, as the question from Jonathan was not about = that.

Given the class= P that defines a protected property with value 1,
and a class C that extends P and re-defines the protected property wit= h the value 2,
please show me an example where yo= u could get from an instance of class C the value 1 of the parent class = property that you think it's shadowed.
Bonus poin= t, if you manage that, you could also set it to something else, and so h= ave a hidden storage for any object of class C that is not really visibl= e normally.

As far as= I know, there is no way to achieve that, and the reason is because at r= untime the objects have a single slot for the protected property; the ch= ild class property overrides the parent class property when redeclared, = and does not shadow it.
But please prove me wrong= .


Thanks,
Alex


I mentioned in my first reply= , there is no way to get an instance-level property unshadowed. It is th= ere though (according to inheritance.c, if I=E2=80=99m reading it right,= it is still accessible, just not from user-land).

<= div>In any case, there are lots of interesting footguns with properties = and inheritance: Problem with abstract neste= d object =C2=B7 Issue #47 =C2=B7 Crell/Serde. 

Could it be considered a bug that my = first example produces a fatal 
error instead of trying t= o access the shadowed parent property that it 
has access= to and is typed to use?

Other lan= guages (such as C#, Java, etc: https://www.programiz.= com/online-compiler/0ud6UO24mHOTU) don=E2=80=99t allow you to access= protected properties/methods on sibling classes. This is because "prote= cted" is usually used in the context of inheritance; access is usually r= estricted to "myself" or "children" and a sibling is neither of those. I= f there is a bug, the bug is that you can access a sibling=E2=80=99s pro= tected properties, at all.

=E2=80=94 Rob

> If there is a bug, the bug is that you can acc= ess a sibling=E2=80=99s protected properties, at all.

In 2006 the absence of this feature was fixed as a bug and meged = in PHP 5.2: htt= ps://bugs.php.net/bug.php?id=3D37632
In 2020 Ni= kita Popov agreed that this is expected: https://x.com/nikita_ppv/status/12= 61633126687805440

So one way is to explicit= ly mention this feature in the Visibility docs and fix the redeclarat= ion issue to make things consistent.

The o= ther way is to deprecate sibling relations.

--
Valentin
<= /div>

I don=E2=80=99t think the redeclar= ation is a bug though, as is mentioned in the linked bug report about pr= operties: https= ://bugs.php.net/bug.php?id=3D37212, it is pretty clear to me that pe= ople expect a redeclaration would be a fatal error, but not accessing a = property declared in a shared parent scope (emphasis mine):
The property is not being rede= clared in C, though. It is still a property of A, structure-wise.= A method declared and called in the same way as the property does n= ot cause any error.

This has been = the case for years, so I don=E2=80=99t think it is a bug. I was only say= ing that if there is a bug, the bug would be that you can access another= class=E2=80=99s protected properties that aren=E2=80=99t a parent or si= bling. I didn=E2=80=99t really go into why, but IMHO, it breaks LSP, sin= ce it allows sibling classes to depend on each other=E2=80=99s internals= , breaking substitutability (particularly in regards to hooks).
=

=E2=80=94 Rob
= --8c1486ba3dd645488ad82cb5dc27995b--