Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126951
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Wed, 26 Mar 2025 01:22:47 +0100
To: internals@lists.php.net
Message-ID: <45ec0bd6-4c65-4059-8cd1-e195f91b5b13@app.fastmail.com>
In-Reply-To: <2512DF25-6B2F-4C18-8F49-17F2665ADB53@rwec.co.uk>
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>
 <2512DF25-6B2F-4C18-8F49-17F2665ADB53@rwec.co.uk>
Subject: Re: [PHP-DEV] RFC: short and inner classes
Content-Type: multipart/alternative;
 boundary=f175133684a24c598d6833613acd5890
From: rob@bottled.codes ("Rob Landers")

--f175133684a24c598d6833613acd5890
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Tue, Mar 25, 2025, at 23:20, Rowan Tommins [IMSoP] wrote:
>=20
>=20
> On 25 March 2025 21:23:48 GMT, Rob Landers <rob@bottled.codes> wrote:
> >
> >> If we didn't have "protected", would you ask the same about "protec=
ted private"? "fileprivate" would be just another access level, not some=
thing you'd combine with existing ones.
> >
> >Actually, probably yes :) Mostly just to ask for clarification. In th=
is case though, we have private(set) and protected(set); would we also w=
ant fileprivate(set)? That's what I was getting at. How do we mix/match =
up all these things?
>=20
>=20
> I don't see what needs deciding - private(set) isn't a new access leve=
l, it's basically sugar for a setter that's marked private.
>=20
> Try replacing "private" with "level1", and "protected" with "level2":
>=20
> level1(set) level2(get) int $foo;
>=20
> And then add "level1a"; can you use it in the same places? Of course:=20
>=20
> level1a(set) level2(get) int $foo;
>=20
> So why would there be any ambiguity about writing this?
>=20
> fileprivate(set) protected(get) int $foo;
>=20
>=20
>=20
> >> > maybe `fileprivate` on a property means `public` in the file, but=
 `private` outside the file. But then how would that intersect with inhe=
ritance?
>=20
>=20
> Just to call back to this: it's like saying "protected means public in=
side the class and its descendants, but private everywhere else". It's a=
n unnecessarily confusing way of describing it, because you then have to=
 define "public" and "private" without the definitions being recursive.
>=20
> A more straightforward description is "protected means accessible insi=
de the class and its descendants, and nowhere else".
>=20
> Maybe having "private" in the name is putting you off, and this is cle=
arer:
>=20
> samefile(set) samemodule(get) int $foo;
>=20
> No "private" or "public" involved anywhere, just descriptions of where=
 the property can be accessed.
>=20

To be clear, I'm not trying to be difficult. As you mentioned, these wer=
e all things I had to think about for nested classes too. I know how nes=
ted classes work and why. How file-private would work, on the other hand=
, I have put little thought into. You say it is obvious (to paraphrase),=
 but the devil is in the details, and there isn't much prior-art to draw=
 from here either.

The only prior art I can think of is Swift's `fileprivate` and C's `stat=
ic`. Beyond that, I am not aware of any other language to offer this fea=
ture. That being said, we can certainly define it any way we want to, bu=
t asking 'dumb questions' and challenging assumptions will help us find =
the rough edges and things we didn't consider before.

> >> I see no reason for inheritance to be involved at all. If we want a=
n access level that means "accessible from any code in this file, or any=
 subclass of the current type", we can make up a keyword for that as wel=
l - "fileprotected", or "fileprivate_or_protected", or whatever.
> >
> >Inheritance gets involved in traits. Traits do "inherit" private acce=
ss properties (currently): https://3v4l.org/89I7A
>=20
>=20
> Traits don't inherit anything, and they don't restrict anything either=
. They paste code in, and once pasted it acts like it was written in the=
 new location. You can even change access levels while pasting, with the=
 syntax "use Foo { bar as public }".
>=20
> The "private" keyword in your example is pasted into class Foo, and me=
ans "accessible within class Foo". It never applies any restriction rela=
tive to trait Bar, because running code never belongs to the trait.
>=20
> A "fileprivate"/"samefile" keyword would be pasted into the file it wa=
s used in, and mean accessible within that file; it wouldn't matter what=
 file the trait was defined in. It would probably be useless, but lots o=
f useless code is possible in any language.

I agree, but these are all things we'd have to consider. I, personally, =
would consider it working the other way around. A trait declaring filepr=
ivate would only be accessible in the trait; otherwise you would have to=
 explain how fileprivate works without saying "the file it is written in=
" and in a way that is easy to understand -- for the RFC + docs. I don't=
 know if it would be useless or useful though. Personally, I'd probably =
implement both ways and see how useful each one is when implementing a t=
oy project and then weigh the pros/cons. It might even be a "why not bot=
h?" type of situation. It's easier to explain if it is both (your descri=
ption above works perfectly for that), but then would allow for some odd=
 behaviors.

=E2=80=94 Rob
--f175133684a24c598d6833613acd5890
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title><style type=3D"text/css">p.Mso=
Normal,p.MsoNoSpacing{margin:0}</style></head><body><div>On Tue, Mar 25,=
 2025, at 23:20, Rowan Tommins [IMSoP] wrote:<br></div><blockquote type=3D=
"cite" id=3D"qt" style=3D""><div><br></div><div><br></div><div>On 25 Mar=
ch 2025 21:23:48 GMT, Rob Landers &lt;<a href=3D"mailto:rob@bottled.code=
s">rob@bottled.codes</a>&gt; wrote:<br></div><div>&gt;<br></div><div>&gt=
;&gt; If we didn't have "protected", would you ask the same about "prote=
cted private"? "fileprivate" would be just another access level, not som=
ething you'd combine with existing ones.<br></div><div>&gt;<br></div><di=
v>&gt;Actually, probably yes :) Mostly just to ask for clarification. In=
 this case though, we have private(set) and protected(set); would we als=
o want fileprivate(set)? That's what I was getting at. How do we mix/mat=
ch up all these things?<br></div><div><br></div><div><br></div><div>I do=
n't see what needs deciding - private(set) isn't a new access level, it'=
s basically sugar for a setter that's marked private.<br></div><div><br>=
</div><div>Try replacing "private" with "level1", and "protected" with "=
level2":<br></div><div><br></div><div>level1(set) level2(get) int $foo;<=
br></div><div><br></div><div>And then add "level1a"; can you use it in t=
he same places? Of course:&nbsp;<br></div><div><br></div><div>level1a(se=
t) level2(get) int $foo;<br></div><div><br></div><div>So why would there=
 be any ambiguity about writing this?<br></div><div><br></div><div>filep=
rivate(set) protected(get) int $foo;<br></div><div><br></div><div><br></=
div><div><br></div><div>&gt;&gt; &gt; maybe `fileprivate` on a property =
means `public` in the file, but `private` outside the file. But then how=
 would that intersect with inheritance?<br></div><div><br></div><div><br=
></div><div>Just to call back to this: it's like saying "protected means=
 public inside the class and its descendants, but private everywhere els=
e". It's an unnecessarily confusing way of describing it, because you th=
en have to define "public" and "private" without the definitions being r=
ecursive.<br></div><div><br></div><div>A more straightforward descriptio=
n is "protected means accessible inside the class and its descendants, a=
nd nowhere else".<br></div><div><br></div><div>Maybe having "private" in=
 the name is putting you off, and this is clearer:<br></div><div><br></d=
iv><div>samefile(set) samemodule(get) int $foo;<br></div><div><br></div>=
<div>No "private" or "public" involved anywhere, just descriptions of wh=
ere the property can be accessed.<br></div><div><br></div></blockquote><=
div><br></div><div>To be clear, I'm not trying to be difficult. As you m=
entioned, these were all things I had to think about for nested classes =
too. I know how nested classes work and why. How file-private would work=
, on the other hand, I have put little thought into. You say it is obvio=
us (to paraphrase), but the devil is in the details, and there isn't muc=
h prior-art to draw from here either.<br></div><div><br></div><div>The o=
nly prior art I can think of is Swift's `fileprivate` and C's `static`. =
Beyond that, I am not aware of any other language to offer this feature.=
 That being said, we can certainly define it any way we want to, but ask=
ing 'dumb questions' and challenging assumptions will help us find the r=
ough edges and things we didn't consider before.</div><div><br></div><bl=
ockquote type=3D"cite" id=3D"qt" style=3D""><div>&gt;&gt; I see no reaso=
n for inheritance to be involved at all. If we want an access level that=
 means "accessible from any code in this file, or any subclass of the cu=
rrent type", we can make up a keyword for that as well - "fileprotected"=
, or "fileprivate_or_protected", or whatever.<br></div><div>&gt;<br></di=
v><div>&gt;Inheritance gets involved in traits. Traits do "inherit" priv=
ate access properties (currently):&nbsp;<a href=3D"https://3v4l.org/89I7=
A">https://3v4l.org/89I7A</a><br></div><div><br></div><div><br></div><di=
v>Traits don't inherit anything, and they don't restrict anything either=
. They paste code in, and once pasted it acts like it was written in the=
 new location. You can even change access levels while pasting, with the=
 syntax "use Foo { bar as public }".<br></div><div><br></div><div>The "p=
rivate" keyword in your example is pasted into class Foo, and means "acc=
essible within class Foo". It never applies any restriction relative to =
trait Bar, because running code never belongs to the trait.<br></div><di=
v><br></div><div>A "fileprivate"/"samefile" keyword would be pasted into=
 the file it was used in, and mean accessible within that file; it would=
n't matter what file the trait was defined in. It would probably be usel=
ess, but lots of useless code is possible in any language.<br></div></bl=
ockquote><div><br></div><div>I agree, but these are all things we'd have=
 to consider. I, personally, would consider it working the other way aro=
und. A trait declaring fileprivate would only be accessible in the trait=
; otherwise you would have to explain how fileprivate works without sayi=
ng "the file it is written in" and in a way that is easy to understand -=
- for the RFC + docs. I don't know if it would be useless or useful thou=
gh. Personally, I'd probably implement both ways and see how useful each=
 one is when implementing a toy project and then weigh the pros/cons. It=
 might even be a "why not both?" type of situation. It's easier to expla=
in if it is both (your description above works perfectly for that), but =
then would allow for some odd behaviors.<br></div><div><br></div><div id=
=3D"sig121229152">=E2=80=94 Rob<br></div></body></html>
--f175133684a24c598d6833613acd5890--