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
