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

On Sat, Nov 8, 2025, at 14:30, Kamil Tekiela wrote: > On Sat, 8 Nov 2025 at 12:44, 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 > > I like the idea except for the name. Why not use the internal keyword > like C# does? > Hi, thanks for the feedback. The main reason I didn’t choose "internal" is that it implies some broader boundary than PHP currently defines. In languages like C#/Kotlin/Swift, "internal" is tied to a module or assembly, not a namespace. PHP doesn’t have a formal module/package boundary today, and I really prefer not to turn this RFC into a discussion about defining one. private(namespace) describes exactly what it does: it widens private to code in the same namespace and nothing beyond that. It doesn’t imply any other boundary or hierarchy. It’s also consistent with asymmetric visibility (public(set)/private(set)/etc), without introducing a new keyword. If we ever introduce modules or packages in the future, internal could certainly be layered on top, or become syntactic sugar over private(namespace) — or some part of it. Much like readonly is now almost syntactic sugar over "public private(set)", other than the write-once restriction. For now, I’m aiming to focus on making internal APIs easier to express without inventing a new packaging system. — Rob