Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128368
Message-ID: <9604c641-fb1d-4c5f-a029-3bfa027bf086@jnvsor.net>
Date: Sat, 2 Aug 2025 14:55:50 +0200
Precedence: list
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] Protected inheritance hierarchies
To: Rob Landers <rob@bottled.codes>
References: <c24d84f3-0d9a-4412-8ea5-a87ebac2e64a@jnvsor.net>
 <2d516e15-2fc7-4ac4-b9c2-7146ac01cfb1@app.fastmail.com>
Content-Language: en-US
Cc: internals@lists.php.net
In-Reply-To: <2d516e15-2fc7-4ac4-b9c2-7146ac01cfb1@app.fastmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-mijn.host-Spamfilter-Domain: mijn.host
X-mijn.host-Spamfilter-Username: 2a03:5180:7:2:f264:726d:beae:1/112
Authentication-Results: mijn.host; auth=pass smtp.auth=2a03:5180:7:2:f264:726d:beae:1/112@mijn.host
X-mijn.host-Spamfilter-Outgoing-Class: ham
X-mijn.host-Spamfilter-Outgoing-Evidence: Combined (0.26)
X-Recommended-Action: accept
X-Filter-ID: 9kzQTOBWQUFZTohSKvQbgI7ZDo5ubYELi59AwcWUnuU/EnE6BIVFkIwEFbebTM9UNaTy/6BmdQaW
 6D8wiBL9Riu2SmbhJN1U9FKs8X3+Nt2sdENNz0Ob5Mcg8HV4NYhqYDYiFl9huZCsZDn+LUJsU4+Q
 4/R2gS5Unx8PNyHFps0EybI1sOftHmSKUCHCvcq0VvcCA1Qa9BGdQX4vJy9/H5JVRKyFCRrxWkR6
 oZhlSr2IwdrR6MCRf9fSYHlHvEpziFKfD1jKgYfH+6S5qDVYoOmeRt7qHd5fQGuXWoplKlc1R6Pa
 oqS3DNVMIxswrKXjmTmYf9felIf8Q0lvYJANy1im26jqdSLearSSTVIJyNKROUzReCS8EpKh0It9
 L25JS816nuiE0t5pG6MLXGczodD6n5G6jw4mRNxot7VM8k9eU13R5GRisKd7Cpd4JJuGILIejoSc
 poot5WKwlo2dbdgFRynr5duqaiP+JtZKoQPGLwTIQNNPqNOPF/so6xWnbVcVWzkLtkIUbefa3NbH
 Kpc59lzUzvTEK+Uqw6PE/u7KuzDY+5x77+RY9BSYyht4On02JTRNJesPXaFd0pgPtOq9wtkIM3Ps
 UTmXxp6BN+taHHderbgAXsu5dIYoVN3LtixBzAFls8HrYidi62+42jPwg3Ran/r0gMtgqwZZbpTE
 LeatZA96RrhoSqJpzM+w1jRaBZLP6jsasJSTg7dcGX6AFEQGoYATRxMWebz+WNWUrbeUFahCzauL
 TLcsDy1G0tyfRa+7DFCbefWZabhQvvTMJKNSKuIt29tfB+vdNqtuQlK+ymUmkYRGmTQkTzoTMxAf
 otCGzDZkl4QlI5v1Yx2lpgkVq+xP9tumT5Y5PbjMdMnLl3/hVAgywsv1hKtMPLbkDqY2eXk4bkT8
 PiChGQnpQfvRxRX1Uq53kUvEQoneq+vfQZNqPqAVT3YaTxZcUV8ShebT8U8Xw9HTDfreWUB3Q2fy
 s6PCXt4asqvGFMrBqnrW+DYb+TAXVZsivwKCr3vxjsH0GFZEcJqbKICEJtWxSVd/lsDmmMOY1jgp
 WTtKcIOSajb4SwOJeYoaS0vLgeY3tKetbIaB909lctYg6sddcUgxA7YvlbL81yrRuBH10tfqoGlb
 dTkTLaWCAXLaltNBJJmzUi3BRF4p6e8zRQ==
X-Report-Abuse-To: spam@filter101.mijn.host
X-Complaints-To: abuse@filter101.mijn.host
From: jnv@jnvsor.net (Jonathan Vollebregt)

On 8/2/25 11:07 AM, Rob Landers wrote:
> 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 <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.
> 
> — Rob

Ah I see, thanks.

Both getProperties and array casting clobber the shadowed protected 
properties (Unlike private properties) but you can access the property 
with reflection by reflecting the parent class.

Could it be considered a bug that my first example produces a fatal 
error instead of trying to access the shadowed parent property that it 
has access to and is typed to use?

I guess that would introduce either too much of a performance penalty 
recursively checking access for each protected property read, or too 
much complexity trying to pin down the variable type at parse time.

Thanks for the info!