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]

Reply via email to