On Sat, Nov 8, 2025, at 18:43, Faizan Akram Dar wrote: > Hi, > > I like the proposal however the choice of syntax seems inconsistent. > > Traditionally visibility is defined by a single keyword like private, > protected, etc, each implicitly defining the scope from which the property is > accessible. > > Aviz (PHP 8.4) added the possibility of defining the operations that can be > performed in the given scope like (get) or (set), the scope however is still > defined by the existing keywords (private for class scope and protected for > child scope). > As such, I'd suggest to use a dedicated keyword for namespace level > visibility like "internal" or "ns-private", the operations will still be > defined within braces (). > > > An excerpt from future scope of aviz rfc differentiating between visibility > and operations. > > > At this time, there are only two possible operations to scope: read and > > write. In concept, additional operations could be added with their own > > visibility controls. Possible examples include: > protected(&get) - Vary whether a reference to a property can be obtained > independently of getting the value. (Would override the set visibility if > used.) > private(setref) - Allows a property to be set by reference only from certain > scopes. > > > -- > > > Faizan Akram Dar > https://faizanakram.me > > > On Sat, 8 Nov 2025, 14:21 Rob Landers, <[email protected]> wrote: >> __ >> Hello Internals, >> >> I’d like to introduce an RFC for discussion: >> https://wiki.php.net/rfc/namespace_visibility which proposes a new >> visibility modifier: private(namespace). >> >> This idea has appeared several times in previous threads but never >> progressed to a formal proposal (from what I could find). My hope is that >> with defined semantics, examples, and implementation details, we can >> evaluate it properly and see whether there’s support for moving forward. >> Feedback is very welcome. >> >> Sincerely, >> >> Rob Landers
Please remember to bottom post! The reason I chose private(namespace) rather than a new keyword is that the semantics are fundamentally a widened form of private. Access is granted to code in the exact same namespace and nowhere else. There's no additional scope concept beyond that. Introducing a new keyword like internal or ns-private suggests a new typeof boundary rather than a refinement on existing ones. In other languages, internal et al. is tied to a module, assembly, crate, and not a namespace. PHP doesn’t have a formal module boundary today, and adopting the term internal would imply we’re defining one. Sidenote: When I proposed nested classes earlier this year, the conversation quickly shifted into what "packages" or "modules" should mean for PHP, and that ended up becoming a much larger debate. I’d like to avoid pulling that discussion into this RFC. It’s a related, but orthogonal topic and could absolutely be explored in a *separate thread.* private(namespace) follows the same syntactic pattern introduced in asymmetric visibility: a base keyword with a parenthesised refinement. In AViz, the refinement controls operations (set/get) and here it refines which callers are allowed. The syntax feels familiar and doesn’t require introducing a new keyword. If we end up introducing modules/packages in a future RFC, a dedicated keyword like internal could absolutely build on top of this. For now, the goal of this RFC is to make a small, well-defined improvement that can be improved upon in future RFCs. — Rob
