On 25 May 2018 13:29:41 BST, "Christoph M. Becker" <cmbecke...@gmx.de> wrote: > > On 17.05.2018 at 12:12, Andrey O Gromov wrote: > > Please take a look on patch "EN error fixed" from user "rjhdby" >> >> >> <emphasis>protected</emphasis> or >> <emphasis>private</emphasis>. Class members declared public can be >> accessed everywhere. Members declared protected can be accessed >> - only within the class itself and by inheriting and parent >> - classes. Members declared as private may only be accessed by the >> + only within the class itself and by inheriting. >> + Members declared as private may only be accessed by the >> class that defines the member. >> </para> >> - >> + <note>You can access protected members of a class or object from >> inherited methods. >> + Do <emphasis>NOT</emphasis> rely on this behavior, because it can be >> changed at any time.</note> >> <sect2 xml:id="language.oop5.visibility-members"> >> <title>Property Visibility</title> >> <para> >> > > I think we should discuss this on the internals@ mailing list. Perhaps > the current behavior is by design, and will “never” change. > > I'm not sure what exactly is "ambiguous" or "might change" here. The current text accurately describes what "protected" means in PHP, and in many other languages: a property which may be accessed only within the current class, classes inheriting from it, and classes from which it inherits.
It may seem odd at first that a parent class can access protected members of a child class, but this is actually a necessary consequence of the child class being able to *override* that member. Consider this pattern: class A { public function something() { // important logic $this->onSomethingHook($someEventData); // more important logic } protected function onSomethingHook($someEventData) { // No logic; extension point provided for sub-classes to add custom behaviour // Could even be declared abstract if this is an abstract base class and a required hook } } class B extends A { protected function onSomethingHook($someEventData) { // Custom logic here, which will be called from class A } } This relies on code in class A being able to call the protected method in class B. Given that PHP is largely "duck typed", it would also be possible for class A to never declare the onSomethingHook method, and call it anyway (maybe checking with method_exists first): https://3v4l.org/hOEuO If this isn't the aspect of the current wording that was confusing, please can you clarify, as the proposed edit seems to me to be just plain wrong. Regards, -- Rowan Collins [IMSoP]