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

On Sat, Nov 8, 2025, at 5:13 PM, Rowan Tommins [IMSoP] wrote: > On 08/11/2025 21:56, Rob Landers wrote: >> One advantage of keeping this RFC small is that it can be expanded >> later without a BC break. For example, prefix matching (maybe >> something like private(namespace: Acme\AuthLib)) or a >> protected-namespace variant could be layered on top if the community >> wants to go in that direction. > > That's a reasonable argument, but the risk is that if we don't consider > what that future scope would look like, we can end up with syntax or > semantics that makes our lives unnecessarily difficult later. As I > understand it, this happened to some extent with the "readonly" keyword. Exactly the example I was thinking of. :-) "Junior version first" approaches sometimes work out (FCC doesn't seem to have caused issues for PFA in practice), and other times not (readonly was a major PITA for aviz, and even delayed it for a release as we figured out how they should interact). I'd much rather know what the "full solution" looks like and plan for it, even if it's in incremental steps, than throw a junior version at the wall and hope for the best. >> This RFC isn’t intended to solve the entire space; it’s the smallest >> useful step that seems to fairly cleanly fit into PHP’s current model >> without too much churn on the engine. > > I think my fundamental question is: is it actually that useful? How > often, in practice, do people want exact namespace matching, vs > something more flexible? In practice, the extra-class boundary I most often want is "my composer package." I rarely need to protect things beyond that. I am broadly in favor of extra-class visibility controls, whether they go through a module system or something else. Whether the current RFC is a good way of doing so, I am not convinced. In particular, the syntax is a hard-no. It runs contrary to how the aviz syntax was defined, as others have already noted. If you don't want to use internal(set) to save internal for some other use, that's fine. Come up with a different keyword. :-) But <allowed scope>(<operation>) is the syntax model that aviz established, and tossing extra parens in there just confuses things for everyone. If it really does need to be an entirely separate dimension of scoping, then I would argue it's too complex to capture in just keywords and Rowan's attribute proposal becomes even more compelling. That said, I'm not convinced it is a separate dimension yet. I'd put "nsviz" between public and protected, not protected and private. The assumption is that your "allowed" scope is something you control. So if you don't want to use that property from child classes in your own namespace... just don't. If you don't want to allow it to be used by child classes in another namespace... then nsviz(get) solves that problem. I will also note that while it's typical for namespace and file path to be 1:1, there's nothing that requires it. That means any strictly namespace-based visibility is trivial to bypass. For example: // vendor/foo/bar/Baz.php namespace Foo\Bar\Baz; class Careful { nsviz string $secret; } // /app/User.php namespace Foo\Bar; class Invader { public function hax(Careful $c): string { return $c->secret; } } namespace App; class User { public function doStuff(Careful $c) { $secret = new Foo\Bar\Invader($c)->hax(); // Boom, we've read the value. } } Whether that is a design flaw or a feature is, I suppose, debatable. --Larry Garfield