Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129183
Message-ID: <c6ac9820-e35e-4fb2-80c5-ee0050cc5e91@bastelstu.be>
Date: Sun, 9 Nov 2025 21:51:33 +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>
Content-Language: en-US
In-Reply-To: <1606b9e5-62b8-446b-adac-519ac19d01c3@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/9/25 18:20, Rob Landers wrote:
> What this RFC does is provide a useful, enforceable intermediate step that doesn’t require the community to solve “packages” first. If we require a full module system before adding any visibility improvements, we’re essentially saying that no incremental progress is acceptable until the hardest part of the problem is fully solved. That’s historically not how PHP evolves.
> […]
> Namespace visibility is intentionally small, intentionally conservative, and intentionally compatible with whatever direction modules eventually take. It’s the smallest useful step the language can take today, without blocking future work, while still being useful.

As I believe I had previously said before, I'm in favor of small RFCs 
and features *that compose well*. I am therefore generally sympathetic 
towards making small incremental improvements with a bigger picture in 
mind. Features that compose well make the language easier to learn and 
understand. This was an important part of the decision why Volker and I 
ultimately decided to use an array parameter for clone-with. And also 
why it was important to me that the pipe operator and partial-function 
application are independently usable feature

For this one I am however not sure if it ticks the “composes well” 
checkbox - that greatly depends on the syntax choice and how modules 
will look like if/when they eventually arrive.

I also believe that the current usefulness is debatable, especially when 
considering how folks are already structuring their applications as of 
now (as indicated by Rowan) and when also considering the ecosystem impact.

Your RFC appears to use the old template for the “RFC Impact” section 
which doesn't yet include the “Ecosystem Impact” subsection, but 
indicating that “significant OPcache changes” are required makes me 
wonder about the cost-benefit ratio.

> Aviz establishes `visibility(operation)` as the pattern for asymmetric visibility, where the keyword controls the caller set and parentheses restrict the operation (get/set). That’s why `private(namespace)(set)` follows the same rule: the base visibility is still "private", and the parentheses narrows who may call it.
> 
> If we introduced a standalone keyword like `internal` or `nsviz`, we’d effectively be adding a new visibility class, not a refinement of `private` and would bring its own semantics, collision issues, and interactions with any future module work. This RFC aims to minimise surface area, which is why it treats namespace visibility as a refinement.

As noted in my reply in the thread from Faizan, calling this a 
refinement of `private` is not really accurate / doesn't work in practice.

> If the community prefers prefix-based visibility or package-level visibility, that could be explored in a follow-up RFC. I’m not opposed to more expressive forms; I’m just not binding this RFC to a package model the language hasn’t defined yet.

To do so, the syntax would need to account for that. I have not yet seen 
a good proposal for that that doesn't end up as “symbol soup” that 
doesn't really fit the existing language syntactically.

> And lastly, isn’t namespace visibility easy to bypass?
> 
> Yes — but so is private and protected. No PHP visibility is intended as a security boundary. This is a developer-intent boundary: encapsulation, static analysis, and making accidental misuse harder.

I fully agree with this part. It's important that bypassing these type 
of control mechanisms is a fairly explicit act that stands out in 
review, but it's not important to lock it down 100% - unless there are 
good (engine-related) reasons to do so.

Best regards
Tim Düsterhus