Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:128371 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 083581A00BC for ; Sat, 2 Aug 2025 17:04:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1754154161; bh=7qKSlGwJlKCLDi8NJI6sHlgLQ03EENjEFxqy3D/tnLo=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=XQK/WKCXDEQkFDPo1n+tTzjWmVXjCSyobSQPM7DlXR2M/IR1+Qft9c/LQUH8ouUZb hvEso+8n1/0tp+hKLhJa62wxeD5BdGoajmvYQwAFNSrwEWZJ2Pv1tSmn8MQWzRB4yR vTfyiPBWkQMihSexGCcZQf5LnvF5kH4dYgSVtQUpcRTWlvnYlkAYo0kRzOdar9qcgr 8CrX6VS+uXV+qhMayYy468h5dv7TXRBnAxFw7h5yOkLGWFk9R7ZLv77xeL1Sqyxa88 hMaralyZGiFUxlkpamKIna4j8ZFQNdxCrROHRLRLcOy/45xw/VG4fgr1PHozajKpMp Xaqc16Igh8gbg== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 6D8EA18007E for ; Sat, 2 Aug 2025 17:02:40 +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=-1.2 required=5.0 tests=BAYES_40,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE, 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 mail-yw1-f175.google.com (mail-yw1-f175.google.com [209.85.128.175]) (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 17:02:40 +0000 (UTC) Received: by mail-yw1-f175.google.com with SMTP id 00721157ae682-71b49a8adb2so26685407b3.1 for ; Sat, 02 Aug 2025 10:04:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1754154261; x=1754759061; darn=lists.php.net; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=7qKSlGwJlKCLDi8NJI6sHlgLQ03EENjEFxqy3D/tnLo=; b=gGvImC9wzcwk8wHBV1iAQUG+qv20o4US7NP4a/MT6iJuFmf1fzSxjKuhHs7lXLe3d6 pHjSclWnFdXvj36lx982A2XCBAzAVuL8weEfWk4l4NZstJbTIa8HlheqWhlspYLr8kDq w9E0JJT/qw5OHP3/jmcEwCpaOINwfLOUES6whfr1b1ErZy1MWoQhipsQFwZ1x0/BIy1D 4ynXfbDO2ngc7wAsrT2Ljmv4BtaZtavlMY8lVnLC3aeq4bzW590zL1JIT8eMkjugwBLO aeU2j8sxTmZrCPE4fFI00dD0j3MdMcIBRWm7MHyCVJtuf081wjX/sZkmALDUYudJ0+5E uIRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1754154261; x=1754759061; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=7qKSlGwJlKCLDi8NJI6sHlgLQ03EENjEFxqy3D/tnLo=; b=Af1g8VdDrb7zYtz4MZHCo5IGG/Lg4IKyFs1/ZIwL2RzE72lIf6jYEqK9HZYTkiAm81 hCenAe4FL5wu/Y6ZIGH1+XYaOYM/JR0NdJFP9skkIuSwhh8XjznC5axt5MyneD1JShFw UKzEE7NU41+9voUGvuM1fAzYLXbmALftAiNkDjv10ZPM92nw+3WyizDWWs+uz94BMPN9 Z+4eFAsu2VLYXHJLV+5vN3cJgEQJlUqCcmtAJ193zHcm7YtZx0g2L71MPCvCOf03iHWl +/wxc/4ZiN/XY2tMykWO0QhQJe+mTPUNGQy6nPfdKprIYXjz8oudurG/zMFcCa/KM5ju AIWg== X-Gm-Message-State: AOJu0YwMezuN8NV3Kp2KPvep7JiUEhajZw2M+cgCwm8IintKQ877zYs6 jgMNF3ubGGmmGe31pGhtGaQ3oPCs2+9a7/S0lYDlLE5gsQ40bNh4dPciq51FwtXUqOe6DGsiPq7 vrHAazMzZpSznJB2oirGEbOFSLB/bN5TFksIR X-Gm-Gg: ASbGncunDN94N1OsgEheFJaBtxKqFfoy05teXKqjJYtwnC+dUzkTnBFtOB6xVEGiVhz WKAwb9oIY9YGE9e+6fN91JJai6BXunHlF4vThhlHALeyUdGyDhPOWZSrDA8hM4NrfjI8cxKOKEJ PdNmn4G4//5yGD+Eji1kYmRpMmptifKKfogtiUVqnbzrBQ7xahFNu+j1lvUPWG0TWNriLgXTPcZ jry9cjQ X-Google-Smtp-Source: AGHT+IHrFtlnChoUdqoYGdiQnTGcvkhw7QiNe8k3vxDzr3eh3XuVMFBZqJgZQYtyb7jT0xpPH6ErDheGWFABm7f035o= X-Received: by 2002:a05:690c:a0ad:10b0:71a:18b5:ef27 with SMTP id 00721157ae682-71b7f5fced1mr30963847b3.18.1754154260488; Sat, 02 Aug 2025 10:04:20 -0700 (PDT) Precedence: list list-help: list-post: List-Id: x-ms-reactions: disallow MIME-Version: 1.0 References: <2d516e15-2fc7-4ac4-b9c2-7146ac01cfb1@app.fastmail.com> <8c60c0b8-8826-49a4-80ba-973ff833fff7@app.fastmail.com> In-Reply-To: <8c60c0b8-8826-49a4-80ba-973ff833fff7@app.fastmail.com> Date: Sat, 2 Aug 2025 20:04:08 +0300 X-Gm-Features: Ac12FXzAcuBbPB-Clwtwg9hZ8lMgdrhzVn4CJ7BRTwF7tjkA2BmF3AjPZ8xeh6s Message-ID: Subject: Re: [PHP-DEV] Protected inheritance hierarchies To: Rob Landers Cc: PHP internals Content-Type: multipart/alternative; boundary="00000000000093e581063b64ddc9" From: drealecs@gmail.com (=?UTF-8?Q?Alexandru_P=C4=83tr=C4=83nescu?=) --00000000000093e581063b64ddc9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Aug 2, 2025, 17:10 Rob Landers wrote: > > > 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 w= rote: > > > 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 > > ...... > > > 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. > > -- > Alex > > > Hi Alex, > > I=E2=80=99m not sure what you mean? https://3v4l.org/WKILh#v8.4.10 > > There is clearly shadowing going on. > > Hi Rob, As I said, let's leave 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 with the value 2, please show me an example where you could get from an instance of class C the value 1 of the parent class property that you think it's shadowed. 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. 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 property; the child class property overrides the parent class property when redeclared, and does not shadow it. But please prove me wrong. Thanks, Alex --00000000000093e581063b64ddc9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Aug 2, 2025, 17:= 10 Rob Landers <rob@bottled.codes> wrote:


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


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

On Tue, Jul 29, 2= 025, at 20:11, Jonathan Vollebregt wrote:
I came across thi= s edge case today:


Both psalm and phpstan think this code is A-OK (Once you = add the=C2=A0
requisite type hints) but it causes fatal errors wa= y 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 ac= cess:=C2=A0https://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 e= xists 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 shad= owing happening in the example.
When the child instance is c= reated, there is just one slot for the property, as the child one replaces = the parent one.
So basically the child property overrides the par= ent property=20 rather than shadowing it.

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

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

I'm wondering now if the access shouldn't be relaxed, in ca= se we have the parent class that initially defined the property.
=
Of course, we should focus on non-static properties, as stat= ic ones are different things, and there is some shadowing there.
=
--=C2=A0
Alex
<= br>
Hi Alex,

I=E2=80=99m not sure what y= ou mean?=C2=A0https://3v4l.org/WKILh#v8.4.10

<= div>There is clearly shadowing going on.


Hi Rob,

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

<= /div>
Given the class P that defines a protected property = with value 1,
and a class C that extends P and re-de= fines the protected property with the value 2,
pleas= e show me an example where you could get from an instance of class C the va= lue 1 of the parent class property that you think it's shadowed.
<= div dir=3D"auto">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.

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 re= declared, and does not shadow it.
But please prove m= e wrong.


Thanks,
Alex
--00000000000093e581063b64ddc9--