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