Re: RFC: Namespace-Scoped Visibility for Methods and Properties

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, <rob@bottled.codes> 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