Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126942
Feedback-ID: id5114917:Fastmail
Date: Tue, 25 Mar 2025 21:05:49 +0000
To: internals@lists.php.net
Subject: Re: [PHP-DEV] RFC: short and inner classes
User-Agent: K-9 Mail for Android
In-Reply-To: <f4ecdf20-b3e4-4316-8a90-4ecc57abd84a@app.fastmail.com>
References: <aae32397-0567-417f-adbe-6b663d5c49ae@app.fastmail.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>
Message-ID: <B3AFADFC-4714-486B-A824-4F3F3B55F45C@rwec.co.uk>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")



On 25 March 2025 20:29:16 GMT, Rob Landers <rob@bottled=2Ecodes> wrote:
> Personally, I'd feel that file-private should be kept as simple as possi=
ble and limit it to "top-level" things, but that doesn't necessarily have t=
o be the case=2E If we did allow it on methods/properties, when mixing it w=
ith regular visibility, what happens? `fileprivate public private(set)` =2E=
=2E=2E means what exactly?


If we didn't have "protected", would you ask the same about "protected pri=
vate"? "fileprivate" would be just another access level, not something you'=
d combine with existing ones=2E


> maybe `fileprivate` on a property means `public` in the file, but `priva=
te` outside the file=2E But then how would that intersect with inheritance?


That was the point of my philosophical rambling about Swift: you don't hav=
e to define new access levels in relation to old ones, or new features as e=
xceptions to old definitions=2E

You can just define the keywords you allow, and the access they provide=2E=
 That's true whether you're defining "private", "fileprivate", or "access_l=
evel_42"=2E

For instance, "fileprivate" could simply mean "accessible from any code de=
fined in this file"=2E Since classes are fully declared in one file, that m=
akes it a strict superset of the access currently meant by "private", and a=
pplies equally well to a whole type, a method, or a property=2E

I see no reason for inheritance to be involved at all=2E If we want an acc=
ess level that means "accessible from any code in this file, or any subclas=
s of the current type", we can make up a keyword for that as well - "filepr=
otected", or "fileprivate_or_protected", or whatever=2E


Rowan Tommins
[IMSoP]