Re: Re: Re: Ambiguity in the oop5 visibility docs

On 28.03.2019 at 10:32, Nikita Popov wrote: > On Tue, May 29, 2018 at 1:41 PM Rowan Collins <rowan.collins@gmail.com> > wrote: > >> On 27 May 2018 at 19:02, Andrew Gromov <andrewgrom@rambler.ru> wrote: >> >>> class A { >>> public function foo(){ >>> echo $this->b; // No property $b in parent class >>> } >>> } >>> >>> class B extends A { >>> protected $b = 'foo'; >>> } >>> >>> $a = new B(); >>> $a->foo(); // prints 'foo' >>> >>> In classic OOP, parent class can't access unknown to him member of child >>> class. >>> >> >> >> In PHP, classes don't really "know" anything about their structure - >> everything is looked up dynamically at run-time. At run-time, there is a >> property called "b" on the instance, and it is visible in the current >> scope, so the access is allowed. >> >> You mention "classic OOP", but I'm not aware of any formal definition we >> could reference here, only precedent from other languages. Most languages >> don't need to worry about this case, because the reference to $this->b >> would fail to compile unless b was declared; but PHP can't raise that >> error, because accessing a completely undeclared property is allowed. >> >> >> >> >>> And phrases like >>> >>>> can be accessed within the class itself and parent classes. >>> >>> explode the brain! How it can be - reverse inheritance, from child to parent!? >>> >>> >> I discussed a common use case for this in my first response on this >> thread: >> https://marc.info/?l=phpdoc&m=152727049709620&w=2 >> >> There is no *inheritance* from child to parent, just access from code >> written in a parent class to polymorphic behaviour in the child class. >> > > Want to bump this discussion again, because I still think that the current > behavior is incorrect. I think there are two different cases that got > conflated here: > > // This should work. > class A { > protected function foo() {} > } > class B extends A { > protected function test() { $this->foo(); } > } > class C extends B { > protected function foo() {} > } > (new C)->test(); > > This code should of course work. It should work because we have an A::foo() > method (the "prototype"), which happens to be overridden by C::foo(), but > that's not actually relevant. The inheritance check here is whether B has > access to the prototype A::foo(), which is has. If you consider that > inheritance is checked against the prototype, then there is actual "reverse > visibility" going on here. > > The other case, and the case that I believe should not work, is the > following: > > // This shouldn't work, but does. > class A { > protected function test() { $this->foo(); } > } > class B extends A { > protected function foo() {} > } > (new B)->test(); > > Here B::foo() does not have a prototype higher up in the hierarchy. We're > calling B::foo() from A, which should by any reasonable interpretation not > be possible. To allow this call, it should be necessary to also add a > protected function foo() to class A, possibly as an abstract method: > > // This should work. > abstract class A { > protected abstract function foo(); > protected function test() { $this->foo(); } > } > class B extends A { > protected function foo() {} > } > (new B)->test(); > > Here once again B::foo() overrides the prototype A::foo(), and A::foo() is > of course visible from A. > > I believe that the current behavior is a leftover from before the > introduction of the prototype mechanism in PHP 5.2. Previously just > checking visibility in both directions was a poor mans approximation of the > correct behavior. However, it both disallowed some legal cases (involving > non-linear hierarchies) and allowed illegal cases (accessing protect method > from a child). > > Since PHP 5.2 all the legal cases should be covered by the prototype > mechanism and the bidirectional visibility check is just a legacy leftover. > We should consider removing it for PHP 8. Changing the actual behavior should better be discussed on internals@, though. :) -- Christoph M. Becker