Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128369
Precedence: list
MIME-Version: 1.0
References: <c24d84f3-0d9a-4412-8ea5-a87ebac2e64a@jnvsor.net> <2d516e15-2fc7-4ac4-b9c2-7146ac01cfb1@app.fastmail.com>
In-Reply-To: <2d516e15-2fc7-4ac4-b9c2-7146ac01cfb1@app.fastmail.com>
Date: Sat, 2 Aug 2025 17:04:47 +0300
Message-ID: <CAAwdEzCG-6Cfgiwa2g-c51_kz8VVMPcHN6pov7EWhE-rO2y=Ug@mail.gmail.com>
Subject: Re: [PHP-DEV] Protected inheritance hierarchies
To: Rob Landers <rob@bottled.codes>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000729b6e063b625ca0"
From: drealecs@gmail.com (=?UTF-8?Q?Alexandru_P=C4=83tr=C4=83nescu?=)

--000000000000729b6e063b625ca0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, Aug 2, 2025 at 12:10=E2=80=AFPM Rob Landers <rob@bottled.codes> wro=
te:

> On Tue, Jul 29, 2025, at 20:11, Jonathan Vollebregt wrote:
>
> I came across this edge case today:
>
> https://3v4l.org/R3Q8D
>
> Both psalm and phpstan think this code is A-OK (Once you add the
> requisite 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 with 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 memory; just accessing it is the hard part.
>
> =E2=80=94 Rob
>


Hi Rob,

I'm pretty sure that there is no shadowing happening in the example.
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 rather 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
is this sibling class access issue.

I'm wondering now if the access shouldn't be relaxed, in case we have the
parent class that initially defined the property.

Of course, we should focus on non-static properties, as static ones are
different things, and there is some shadowing there.

--=20
Alex

--000000000000729b6e063b625ca0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote g=
mail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Sat, Aug 2, =
2025 at 12:10=E2=80=AFPM Rob Landers &lt;rob@bottled.codes&gt; wrote:<br></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u><div><div>On T=
ue, Jul 29, 2025, at 20:11, Jonathan Vollebregt wrote:</div><blockquote typ=
e=3D"cite" id=3D"m_6994282754719696319qt"><div>I came across this edge case=
 today:</div><div><br></div><div><a href=3D"https://3v4l.org/R3Q8D" target=
=3D"_blank">https://3v4l.org/R3Q8D</a></div><div><br></div><div>Both psalm =
and phpstan think this code is A-OK (Once you add the=C2=A0</div><div>requi=
site type hints) but it causes fatal errors way back to PHP 5.0.0</div><div=
><br></div><div>...&lt;snip&gt;...</div></blockquote><div><br></div><div>It=
&#39;s not an edge case, in C2, you redefine a protected variable with the =
same name and shadowed the original $v. That $v is different than C&#39;s $=
v. It&#39;s easiest to see this with static access:=C2=A0<a href=3D"https:/=
/3v4l.org/0SRWb#v8.4.10" target=3D"_blank">https://3v4l.org/0SRWb#v8.4.10</=
a><br></div><div><br></div><div>However, I don&#39;t know of any way to uns=
hadow a property from $this to access the ancestor&#39;s value (other than =
using private access), but it exists and takes up memory; just accessing it=
 is the hard part.</div><div><br></div><div id=3D"m_6994282754719696319sig1=
21229152">=E2=80=94 Rob</div></div></blockquote><div><br></div><div><br></d=
iv><div>Hi Rob,</div><div><br></div><div>I&#39;m pretty sure that there is =
no shadowing happening in the example.</div><div>When the child instance is=
 created, there is just one slot for the property, as the child one replace=
s the parent one.<br>So basically the child property overrides the parent p=
roperty=20

rather than shadowing it.</div><div><br></div><div>True shadowing (two slot=
s) only occurs when the parent property is declared private.</div><div><br>=
</div><div>It&#39;s just that when redefining, it stores the declaring clas=
s, and so there is this sibling class access issue.</div><div><br></div><di=
v>I&#39;m wondering now if the access shouldn&#39;t be relaxed, in case we =
have the parent class that initially defined the property.</div><div><br></=
div><div>Of course, we should focus on non-static properties, as static one=
s are different things, and there is some shadowing there.</div><div><br></=
div><div>--=C2=A0</div><div>Alex</div></div></div>

--000000000000729b6e063b625ca0--