Re: Protected inheritance hierarchies

On Sat, Aug 2, 2025, at 22:18, Valentin Udaltsov wrote: > On Sat, Aug 2, 2025, at 22:17, Rob Landers <rob@bottled.codes> wrote: >> __ >> 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 > > > If there is a bug, the bug is that you can access a sibling’s protected properties, at > > all. > > In 2006 the absence of this feature was fixed as a bug and meged in PHP 5.2: > https://bugs.php.net/bug.php?id=37632 > In 2020 Nikita Popov agreed that this is expected: > https://x.com/nikita_ppv/status/1261633126687805440 > > So one way is to explicitly mention this feature in the Visibility docs > <https://www.php.net/manual/en/language.oop5.visibility.php> > and fix the redeclaration issue to make things consistent. > > The other way is to deprecate sibling relations. > > -- > Valentin I don’t think the redeclaration is a bug though, as is mentioned in the linked bug report about properties: https://bugs.php.net/bug.php?id=37212, it is pretty clear to me that people expect a redeclaration would be a fatal error, but not accessing a property declared in a shared parent scope (emphasis mine): > The property *is not being redeclared in C*, though. *It is still a property of A, > structure-wise.* A method declared and called in the same way as the property does not cause any > error. This has been the case for years, so I don’t think it is a bug. I was only saying that if there is a bug, the bug would be that you can access another class’s protected properties that aren’t a parent or sibling. I didn’t really go into why, but IMHO, it breaks LSP, since it allows sibling classes to depend on each other’s internals, breaking substitutability (particularly in regards to hooks). — Rob