Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126944
Feedback-ID: id5114917:Fastmail
Date: Tue, 25 Mar 2025 22:20:13 +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: <f8a2377f-aeaf-4092-a967-4049de47ede7@app.fastmail.com>
References: <aae32397-0567-417f-adbe-6b663d5c49ae@app.fastmail.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> <B3AFADFC-4714-486B-A824-4F3F3B55F45C@rwec.co.uk> <f8a2377f-aeaf-4092-a967-4049de47ede7@app.fastmail.com>
Message-ID: <2512DF25-6B2F-4C18-8F49-17F2665ADB53@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 21:23:48 GMT, Rob Landers <rob@bottled=2Ecodes> wrote:
>
>> If we didn't have "protected", would you ask the same about "protected =
private"? "fileprivate" would be just another access level, not something y=
ou'd combine with existing ones=2E
>
>Actually, probably yes :) Mostly just to ask for clarification=2E In this=
 case though, we have private(set) and protected(set); would we also want f=
ileprivate(set)? That's what I was getting at=2E How do we mix/match up all=
 these things?


I don't see what needs deciding - private(set) isn't a new access level, i=
t's basically sugar for a setter that's marked private=2E

Try replacing "private" with "level1", and "protected" with "level2":

level1(set) level2(get) int $foo;

And then add "level1a"; can you use it in the same places? Of course:=20

level1a(set) level2(get) int $foo;

So why would there be any ambiguity about writing this?

fileprivate(set) protected(get) int $foo;



>> > maybe `fileprivate` on a property means `public` in the file, but `pr=
ivate` outside the file=2E But then how would that intersect with inheritan=
ce?


Just to call back to this: it's like saying "protected means public inside=
 the class and its descendants, but private everywhere else"=2E It's an unn=
ecessarily confusing way of describing it, because you then have to define =
"public" and "private" without the definitions being recursive=2E

A more straightforward description is "protected means accessible inside t=
he class and its descendants, and nowhere else"=2E

Maybe having "private" in the name is putting you off, and this is clearer=
:

samefile(set) samemodule(get) int $foo;

No "private" or "public" involved anywhere, just descriptions of where the=
 property can be accessed=2E




>> I see no reason for inheritance to be involved at all=2E If we want an =
access level that means "accessible from any code in this file, or any subc=
lass of the current type", we can make up a keyword for that as well - "fil=
eprotected", or "fileprivate_or_protected", or whatever=2E
>
>Inheritance gets involved in traits=2E Traits do "inherit" private access=
 properties (currently): https://3v4l=2Eorg/89I7A


Traits don't inherit anything, and they don't restrict anything either=2E =
They paste code in, and once pasted it acts like it was written in the new =
location=2E You can even change access levels while pasting, with the synta=
x "use Foo { bar as public }"=2E

The "private" keyword in your example is pasted into class Foo, and means =
"accessible within class Foo"=2E It never applies any restriction relative =
to trait Bar, because running code never belongs to the trait=2E

A "fileprivate"/"samefile" keyword would be pasted into the file it was us=
ed in, and mean accessible within that file; it wouldn't matter what file t=
he trait was defined in=2E It would probably be useless, but lots of useles=
s code is possible in any language=2E


Besides, all these questions have to be answered for nested classes as wel=
l=2E Just because you've reused the keyword "private" rather than adding "p=
rivate_or_nested", you still have to define exactly what it does and doesn'=
t allow access from in these new scopes=2E


Rowan Tommins
[IMSoP]