Re: Protected inheritance hierarchies

On Sat, Aug 2, 2025, at 19:04, Alexandru Pătrănescu wrote: > > > On Sat, Aug 2, 2025, 17:10 Rob Landers <rob@bottled.codes> wrote: >> __ >> >> >> 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. >> >> > > 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 > I mentioned in my first reply, there is no way to get an instance-level property unshadowed. It is there though (according to inheritance.c, if I’m reading it right, it is still accessible, just not from user-land). In any case, there are lots of interesting footguns with properties and inheritance: Problem with abstract nested object · Issue #47 · Crell/Serde <https://github.com/Crell/Serde/issues/47#issuecomment-1890966829>. > 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? Other languages (such as C#, Java, etc: https://www.programiz.com/online-compiler/0ud6UO24mHOTU) don’t allow you to access protected properties/methods on sibling classes. This is because "protected" is usually used in the context of inheritance; access is usually restricted to "myself" or "children" and a sibling is neither of those. If there is a bug, the bug is that you can access a sibling’s protected properties, at all. — Rob