Re: Protected inheritance hierarchies

On Sat, Aug 2, 2025, at 16:04, Alexandru Pătrănescu wrote: > > > On Sat, Aug 2, 2025 at 12:10 PM Rob Landers <rob@bottled.codes> wrote: >> __ >> 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. >> >> — 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’m not sure what you mean? https://3v4l.org/WKILh#v8.4.10 There is clearly shadowing going on. — Rob