Hi
On 11/10/25 20:19, Rob Landers wrote:
Updated RFC:
https://wiki.php.net/rfc/namespace_visibility
<https://wiki.php.net/rfc/namespace_visibility?utm_source=chatgpt.com>
From the RFC I'm seeing that it's legal to redefine methods in
different namespaces? I've only figured that out with the last example
in the “Preventing Visibility Reduction and Incompatible Redeclaration”
section, it might have been hinted at with “However, visibility is
enforced based on the namespace where they were declared, not on the
inheritance hierarchy:” but if it did, I didn't understand it.
I also don't believe it's useful to allow redefining namespace-scoped
methods from a different namespace, since they would be *severely*
restricted and also confusing. Consider:
namespace Foo {
class P {
private(namespace) function x() { }
}
}
namespace Bar {
class C extends Foo\P {
private(namespace) function x() {
parent::x(); // illegal
}
}
$c = new C();
$c->x(); // also illegal, despite C being in the current
namespace, so everything should be accessible.
}
I stay with my previous note that cross-namespace inheritance becomes
unsound (and confusing) once namespace-scoped symbols are involved.
I feel that namespace-scoping needs to be restricted to top-level
symbols to be easy to reason about. This also brings me to the next
point: What about free-standing functions and constants?
public/protected/private doesn't make sense for them, since they are not
part of a inheritance hierarchy. But namespace-scope would be meaningful.
All in all, I feel that file-private symbols would solve many of the
same problems, but be much easier to reason about. The SessionManager
from your example could just be file-private.
Best regards
Tim Düsterhus
