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
