Re: RFC: Namespace-Scoped Visibility for Methods and Properties
On Sun, Nov 9, 2025, at 19:01, Tim Düsterhus wrote:
> Hi
>
> On 11/9/25 16:07, Rob Landers wrote:
> > I’ve updated the RFC and implementation accordingly along with some editorial changes.
>
> From what I see the RFC does not discuss the following at all:
>
> class P {
> protected function x() { }
> }
> class C extends P {
> private(namespace) function x() { }
> }
>
> and vice versa:
>
> class P {
> private(namespace) function x() { }
> }
> class C extends P {
> protected function x() { }
> }
>
> Best regards
> Tim Düsterhus
Good catch! The RFC should spell out these cases directly. The behaviour follows the same rule PHP
already applies to private during inheritance:
class P {
protected function x() {}
}
class C extends P {
private(namespace) function x() {}
}
Reducing visibility is an error. This is rejected for the same reason that redefining a protected
method as private is rejected today: C::x() would be less visible than
P::x().
private(namespace) doesn’t introduce any new ambiguity here. The name even implies
that visibility will be reduced and lives below protected in the caller set, so reducing visibility
is not allowed.
class P {
private(namespace) function x() {}
}
class C extends P {
protected function x() {}
}
This behaves the same as overriding a private method with a protected/public one today: the
parent’s method is private to its declaring class, so the second example is allowed.
I’ll update the RFC to explicitly document both of these cases so the inheritance rules are
unambiguous.
Thanks for pointing it out.
— Rob
Thread (32 messages)