Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129168
Feedback-ID: i8414410d:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Sun, 09 Nov 2025 09:33:36 -0600
To: "php internals" <internals@lists.php.net>
Message-ID: <8978174c-04fc-451a-8bf5-cb7c54346318@app.fastmail.com>
In-Reply-To: <2d9f8f1d-e568-4bb5-b30c-0a9e54a8f5fe@rwec.co.uk>
References: <e21b1992-d426-46cd-b86a-6d6a5844c934@app.fastmail.com>
 <f1f694d7-d494-45c5-a4e4-fb39809d3b67@rwec.co.uk>
 <c0bfa15e-1df2-4d87-8092-2531b2bafcb3@app.fastmail.com>
 <72f90052-fa19-415c-9f5a-ae75275fd030@rwec.co.uk>
 <be5c97b7-430d-4d4e-b413-b331c85816e1@app.fastmail.com>
 <2d9f8f1d-e568-4bb5-b30c-0a9e54a8f5fe@rwec.co.uk>
Subject: Re: [PHP-DEV] RFC: Namespace-Scoped Visibility for Methods and Properties
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

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=20
>> later without a BC break. For example, prefix matching (maybe=20
>> something like `private(namespace: Acme\AuthLib)`) or a=20
>> protected-namespace variant could be layered on top if the community=20
>> wants to go in that direction.
>
> That's a reasonable argument, but the risk is that if we don't conside=
r=20
> what that future scope would look like, we can end up with syntax or=20
> semantics that makes our lives unnecessarily difficult later. As I=20
> understand it, this happened to some extent with the "readonly" keywor=
d.

Exactly the example I was thinking of. :-)  "Junior version first" appro=
aches 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 inte=
ract).  I'd much rather know what the "full solution" looks like and pla=
n 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=E2=80=99t intended to solve the entire space; it=E2=80=99=
s the smallest=20
>> useful step that seems to fairly cleanly fit into PHP=E2=80=99s curre=
nt model=20
>> without too much churn on the engine.
>
> I think my fundamental question is: is it actually that useful? How=20
> often, in practice, do people want exact namespace matching, vs=20
> 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 g=
o 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 avi=
z syntax was defined, as others have already noted.

If you don't want to use `internal(set)` to save `internal` for some oth=
er use, that's fine.  Come up with a different keyword. :-)  But <allowe=
d scope>(<operation>) is the syntax model that aviz established, and tos=
sing 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 Rowa=
n's attribute proposal becomes even more compelling.

That said, I'm not convinced it is a separate dimension yet.  I'd put "n=
sviz" between public and protected, not protected and private.  The assu=
mption 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 namespac=
e... just don't.  If you don't want to allow it to be used by child clas=
ses 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 names=
pace-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 {=20
    return $c->secret;
 }
}

namespace App;

class User {
  public function doStuff(Careful $c) {
    $secret =3D 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