Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129410
Message-ID: <bd67e375-ecc6-43f9-ae23-196a55d94867@bastelstu.be>
Date: Sun, 23 Nov 2025 17:00:15 +0100
Precedence: list
MIME-Version: 1.0
Subject: Re: [PHP-DEV] RFC: Namespace-Scoped Visibility for Methods and
 Properties
To: Rob Landers <rob@bottled.codes>, internals@lists.php.net
References: <e21b1992-d426-46cd-b86a-6d6a5844c934@app.fastmail.com>
 <f1f694d7-d494-45c5-a4e4-fb39809d3b67@rwec.co.uk>
 <c0bfa15e-1df2-4d87-8092-2531b2bafcb3@app.fastmail.com>
 <72f90052-fa19-415c-9f5a-ae75275fd030@rwec.co.uk>
 <be5c97b7-430d-4d4e-b413-b331c85816e1@app.fastmail.com>
 <2d9f8f1d-e568-4bb5-b30c-0a9e54a8f5fe@rwec.co.uk>
 <8978174c-04fc-451a-8bf5-cb7c54346318@app.fastmail.com>
 <1606b9e5-62b8-446b-adac-519ac19d01c3@app.fastmail.com>
 <c6ac9820-e35e-4fb2-80c5-ee0050cc5e91@bastelstu.be>
 <de42ddbf-1650-4039-b172-c1f26e0c01e1@app.fastmail.com>
 <a7d63636-f079-429f-a57d-111631187e1e@app.fastmail.com>
Content-Language: en-US
In-Reply-To: <a7d63636-f079-429f-a57d-111631187e1e@app.fastmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

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