On 25 May 2018 13:29:41 BST, "Christoph M. Becker" <[email protected]>
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]
