Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126943
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Tue, 25 Mar 2025 22:23:48 +0100
To: internals@lists.php.net
Message-ID: <f8a2377f-aeaf-4092-a967-4049de47ede7@app.fastmail.com>
In-Reply-To: <B3AFADFC-4714-486B-A824-4F3F3B55F45C@rwec.co.uk>
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>
 <B3AFADFC-4714-486B-A824-4F3F3B55F45C@rwec.co.uk>
Subject: Re: [PHP-DEV] RFC: short and inner classes
Content-Type: multipart/alternative;
 boundary=0a598d0619654d91821bbc203969826e
From: rob@bottled.codes ("Rob Landers")

--0a598d0619654d91821bbc203969826e
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Tue, Mar 25, 2025, at 22:05, Rowan Tommins [IMSoP] wrote:
>=20
>=20
> On 25 March 2025 20:29:16 GMT, Rob Landers <rob@bottled.codes> wrote:
> > Personally, I'd feel that file-private should be kept as simple as p=
ossible 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 mix=
ing it with regular visibility, what happens? `fileprivate public privat=
e(set)` ... means what exactly?
>=20
>=20
> If we didn't have "protected", would you ask the same about "protected=
 private"? "fileprivate" would be just another access level, not somethi=
ng you'd combine with existing ones.

Actually, probably yes :) Mostly just to ask for clarification. In this =
case though, we have private(set) and protected(set); would we also want=
 fileprivate(set)? That's what I was getting at. How do we mix/match up =
all these things?

>=20
> > maybe `fileprivate` on a property means `public` in the file, but `p=
rivate` outside the file. But then how would that intersect with inherit=
ance?
>=20
>=20
> That was the point of my philosophical rambling about Swift: you don't=
 have to define new access levels in relation to old ones, or new featur=
es as exceptions to old definitions.
>=20
> You can just define the keywords you allow, and the access they provid=
e. That's true whether you're defining "private", "fileprivate", or "acc=
ess_level_42".
>=20
> For instance, "fileprivate" could simply mean "accessible from any cod=
e defined in this file". Since classes are fully declared in one file, t=
hat makes it a strict superset of the access currently meant by "private=
", and applies equally well to a whole type, a method, or a property.
>=20
> I see no reason for inheritance to be involved at all. If we want an a=
ccess level that means "accessible from any code in this file, or any su=
bclass of the current type", we can make up a keyword for that as well -=
 "fileprotected", or "fileprivate_or_protected", or whatever.
>=20
>=20
> Rowan Tommins
> [IMSoP]

Inheritance gets involved in traits. Traits do "inherit" private access =
properties (currently): https://3v4l.org/89I7A

Would file-private properties/methods also be available outside the file=
, or would those allow access from inside the new file? Or both?

=E2=80=94 Rob
--0a598d0619654d91821bbc203969826e
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><br></div><div>=
<br></div><div>On Tue, Mar 25, 2025, at 22:05, Rowan Tommins [IMSoP] wro=
te:<br></div><blockquote type=3D"cite" id=3D"qt" style=3D""><div><br></d=
iv><div><br></div><div>On 25 March 2025 20:29:16 GMT, Rob Landers &lt;<a=
 href=3D"mailto:rob@bottled.codes">rob@bottled.codes</a>&gt; wrote:<br><=
/div><div>&gt; 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/propertie=
s, when mixing it with regular visibility, what happens? `fileprivate pu=
blic private(set)` ... means what exactly?<br></div><div><br></div><div>=
<br></div><div>If we didn't have "protected", would you ask the same abo=
ut "protected private"? "fileprivate" would be just another access level=
, not something you'd combine with existing ones.<br></div></blockquote>=
<div><br></div><div>Actually, probably yes :) Mostly just to ask for cla=
rification. In this case though, we have private(set) and protected(set)=
; would we also want fileprivate(set)? That's what I was getting at. How=
 do we mix/match up all these things?</div><div><br></div><blockquote ty=
pe=3D"cite" id=3D"qt" style=3D""><div><br></div><div>&gt; maybe `filepri=
vate` on a property means `public` in the file, but `private` outside th=
e file. But then how would that intersect with inheritance?<br></div><di=
v><br></div><div><br></div><div>That was the point of my philosophical r=
ambling about Swift: you don't have to define new access levels in relat=
ion to old ones, or new features as exceptions to old definitions.<br></=
div><div><br></div><div>You can just define the keywords you allow, and =
the access they provide. That's true whether you're defining "private", =
"fileprivate", or "access_level_42".<br></div><div><br></div><div>For in=
stance, "fileprivate" could simply mean "accessible from any code define=
d in this file". Since classes are fully declared in one file, that make=
s 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.<br></div><=
div><br></div><div>I see no reason for inheritance to be involved at all=
. If we want an access level that means "accessible from any code in thi=
s file, or any subclass of the current type", we can make up a keyword f=
or that as well - "fileprotected", or "fileprivate_or_protected", or wha=
tever.<br></div><div><br></div><div><br></div><div>Rowan Tommins<br></di=
v><div>[IMSoP]<br></div></blockquote><div><br></div><div>Inheritance get=
s involved in traits. Traits do "inherit" private access properties (cur=
rently):&nbsp;<a href=3D"https://3v4l.org/89I7A">https://3v4l.org/89I7A<=
/a><br></div><div><br></div><div>Would file-private properties/methods a=
lso be available outside the file, or would those allow access from insi=
de the new file? Or both?</div><div><br></div><div id=3D"sig121229152">=E2=
=80=94 Rob<br></div></body></html>
--0a598d0619654d91821bbc203969826e--