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
