Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126955
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Tue, 25 Mar 2025 23:50:17 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <95d8b8ff-f3af-4e5f-a368-e89dd73be368@app.fastmail.com>
In-Reply-To: <f4ecdf20-b3e4-4316-8a90-4ecc57abd84a@app.fastmail.com>
References: <aae32397-0567-417f-adbe-6b663d5c49ae@app.fastmail.com>
 <CAO__Xv4END_NsATOGSnCArGuP_UmSpMxSMsSNPsQZnLooOWTsQ@mail.gmail.com>
 <3e4ba7ea-a154-452d-abfc-05ef1322fade@app.fastmail.com>
 <AM8P250MB0170DE2A7E1AEE1FE1ED1F7CE2DF2@AM8P250MB0170.EURP250.PROD.OUTLOOK.COM>
 <782d76d9-711a-4cee-ae0e-fe0d69973f53@app.fastmail.com>
 <DU2P250MB0176FD3F525DFCA32D5A55D6E2DE2@DU2P250MB0176.EURP250.PROD.OUTLOOK.COM>
 <48dce917-d147-456b-9f03-c7e23411adff@app.fastmail.com>
 <AM8P250MB0170601416CA1D75F128D80FE2D92@AM8P250MB0170.EURP250.PROD.OUTLOOK.COM>
 <8a16b81c-7dab-4523-a352-76ba0cb4e771@app.fastmail.com>
 <AM8P250MB0170CA8F8094797B55ADE424E2D82@AM8P250MB0170.EURP250.PROD.OUTLOOK.COM>
 <9c4ac301-dfb2-49da-90e5-37a2824fc4e3@app.fastmail.com>
 <AM8P250MB0170330066F90E056EBA76F8E2D82@AM8P250MB0170.EURP250.PROD.OUTLOOK.COM>
 <5b1e6d70-a1c9-455c-93d3-6b22cf1fef11@app.fastmail.com>
 <CAF-mU4zuja0XfemEyC8sJs=+in6Q6F3An7fzWB9+1o31o=Y-8w@mail.gmail.com>
 <efcac45a-60ac-4145-b012-72d5fef0090c@app.fastmail.com>
 <52d84a5b-09d3-4e42-9620-a62fb239c21e@app.fastmail.com>
 <09a82882-f1ee-4bdb-8a27-e46144a711f1@app.fastmail.com>
 <f4ecdf20-b3e4-4316-8a90-4ecc57abd84a@app.fastmail.com>
Subject: Re: [PHP-DEV] RFC: short and inner classes
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
From: larry@garfieldtech.com ("Larry Garfield")

On Tue, Mar 25, 2025, at 3:29 PM, Rob Landers wrote:

> File-private, in my mind, is different; such as when the classes are 
> distinctly unrelated with respect to each other, but nobody else should 
> be able to instantiate or use the private class. It is like it doesn't 
> exist outside that file. For example, something like a log formatter or 
> a default strategy implementation. Personally, I'd feel that 
> file-private should be kept as simple as possible and limit it to 
> "top-level" things, but that doesn't necessarily have to be the case. 
> If we did allow it on methods/properties, when mixing it with regular 
> visibility, what happens? `fileprivate public private(set)` ... means 
> what exactly? I assume we probably wouldn't allow that particular 
> scenario, and maybe `fileprivate` on a property means `public` in the 
> file, but `private` outside the file. But then how would that intersect 
> with inheritance? My point is that I don't think there is an intuitive 
> answer to these behaviors, but at least nested/inner classes, while not 
> 100% intuitive either, at least are available in other languages, so 
> its behavior will be familiar.

The aviz RFC was designed explicitly to support this sort of case. :-)  (Module or file visibility.)  The syntax was borrowed from Swift, which has 5 levels: public, package, internal (within the same module, which is apparently not the same as a package), file-private, and private.

The syntax for a visibility modifier is

$accessLevel($operation)

If the $operation is omitted, it means "any operation not otherwise specified."  Right now the only explicit operation is `set`, though there's no reason `get` couldn't be made available on its own, too.  We didn't, because right now there's no reason *to* do it, either. :-)  But the logical structure is there.

If we add more access levels, we just have more options for that part of the modifier.  If we add more operations, we just have more options for that modifier.

So if, hypothetically, we added a `module` visibility between public and protected, and added support for controlling the ability to unset() a property separately from setting it (for whatever reason, bear with me), the syntax extends to that quite naturally:

public fileprivate(set) private(unset) string $foo;

(With the standalone `public` still being optional.)

Methods only have one action, call, so there's no aviz to consider.  Just `fileprivate function foo(int $a) { ... }`.  

There may be other edge cases and gotchas to consider (eg, traits, as you note), but the syntax to use is already defined.

--Larry Garfield