Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127296
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Tue, 06 May 2025 22:04:28 +0200
To: =?UTF-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>,
 "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>, internals@lists.php.net
Message-ID: <386b4359-be5b-4872-b2c1-c8211a08d7dd@app.fastmail.com>
In-Reply-To: <681845d2-ff1e-4ab8-97b2-50fecfdcb62b@bastelstu.be>
References: <aae32397-0567-417f-adbe-6b663d5c49ae@app.fastmail.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>
 <706e22d7-94eb-44bd-a280-f629ba93b630@app.fastmail.com>
 <03a5b9a8-9fe1-4656-ab04-dd58669488b3@app.fastmail.com>
 <158a5d7c-8ef6-4b5f-b8ef-593879a7a896@bastelstu.be>
 <a2f7ddb0-868e-49d6-b9fe-58d67ec15b08@app.fastmail.com>
 <c70b3646-72ac-45bf-82bc-54c35c69b7b7@bastelstu.be>
 <72ef8352-2afb-4024-b4ae-857fcd94edd6@app.fastmail.com>
 <213a8711-adbc-42b7-bcb8-86e64cb22cf2@bastelstu.be>
 <5A723310-1AB6-4D4A-88CC-52EC4E81AE5C@rwec.co.uk>
 <681845d2-ff1e-4ab8-97b2-50fecfdcb62b@bastelstu.be>
Subject: Re: [PHP-DEV] Re: RFC: Nested Classes
Content-Type: multipart/alternative;
 boundary=91f9711e698a46c49d6bea39f6933770
From: rob@bottled.codes ("Rob Landers")

--91f9711e698a46c49d6bea39f6933770
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Sun, May 4, 2025, at 15:52, Tim D=C3=BCsterhus wrote:
> Hi
>=20
> On 4/30/25 12:51, Rowan Tommins [IMSoP] wrote:
> > I think you are insisting on a different definition of "private" for=
 nested classes than exists anywhere else in the language, and one that =
I've not seen evidence of in any other similar language either. It seems=
 you want members to be "hidden", such that you can't even know they exi=
st.
>=20
> No, I don't think I'm using a different definition of "private" for=20
> nested classes.
>=20
> > More specifically, you want their *fully-qualified name* to somehow =
be available for reuse. That's not how private members of a class work -=
 methods A::foo() and B::foo() have different fully-qualified names, as =
do properties A::$foo and B::$foo, regardless of visibility and inherita=
nce. It's not how "namespace private", "module private", or "file privat=
e" classes would naturally work, because they all would need to be refer=
enceable with fully-qualified names within the scope where they were vis=
ible.
> The difference is that for private class members there is no chance of=20
> name collisions of the "fully-qualified" name, but there is for nested=20
> classes as proposed in this RFC. There is no way for anyone except for=20
> the author of the class `A` to create a property with the fully=20
> qualified name `A::$foo`. Granted, properties could be inherited from =
a=20
> parent class and might thus cause collisions with a private property i=
n=20
> a subclass. However the same collision would happen if the child class=20
> would already have a public property of the same name. Importantly, th=
e=20
> child class could just rename its private property without any effect =
on=20
> any other class and also parent classes can introduce private properti=
es=20
> without any effect on any other class.
>=20
> This is difference for nested classes as proposed in this RFC, since t=
he=20
> namespace of nested classes is shared with the namespace of regular=20
> classes and the namespace of regular classes is not =E2=80=9Cclosed of=
f=E2=80=9D for=20
> addition after the initial declaration.
>=20
> > It's also not a new problem: PHP doesn't enforce a file and director=
y layout, and libraries can and do define things "inside" each other's n=
amespaces. When declaring a class, you have to be aware of whether a cla=
ss with the same fully-qualified name has been, or will be, declared in =
another file.
>=20
> This is correct, but all these other classes that could conflict are=20
> part of the *public API* of a library. But now with private nested=20
> classes I would also be aware of the private part of a library to avoi=
d=20
> conflicts.
>=20
> Best regards
> Tim D=C3=BCsterhus
>=20

Hi Tim,

I think these are fundamental problems (if they are a problem at all) wi=
th how PHP currently does namespaces and names. I'm curious if you would=
 vote "no" for namespace visibility as well? While not intended to be us=
ed as "modules," this has many of the same constraints and effects that =
full namespace visibility would have=E2=80=94including the same problems=
 you allude to here.

As I was going to work on short syntax classes next if this one passed, =
as well as namespace visibility/modules after that (regardless of this R=
FC passing), I'd really like to know if this behavior is that big of an =
issue. If so, it is probably not worth pursuing namespace visibility if =
this RFC fails.

For everyone else who voted "no"; I would sincerely love to know the rea=
son. Even if you just email me directly; it would really help me underst=
and what can be improved in any future RFCs.

=E2=80=94 Rob
--91f9711e698a46c49d6bea39f6933770
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title></head><body><div>On Sun, May =
4, 2025, at 15:52, Tim D=C3=BCsterhus wrote:</div><blockquote type=3D"ci=
te" id=3D"qt" style=3D""><div>Hi</div><div><br></div><div>On 4/30/25 12:=
51, Rowan Tommins [IMSoP] wrote:</div><div>&gt; I think you are insistin=
g on a different definition of "private" for nested classes than exists =
anywhere else in the language, and one that I've not seen evidence of in=
 any other similar language either. It seems you want members to be "hid=
den", such that you can't even know they exist.</div><div><br></div><div=
>No, I don't think I'm using a different definition of "private" for&nbs=
p;</div><div>nested classes.</div><div><br></div><div>&gt; More specific=
ally, you want their *fully-qualified name* to somehow be available for =
reuse. That's not how private members of a class work - methods A::foo()=
 and B::foo() have different fully-qualified names, as do properties A::=
$foo and B::$foo, regardless of visibility and inheritance. It's not how=
 "namespace private", "module private", or "file private" classes would =
naturally work, because they all would need to be referenceable with ful=
ly-qualified names within the scope where they were visible.</div><div>T=
he difference is that for private class members there is no chance of&nb=
sp;</div><div>name collisions of the "fully-qualified" name, but there i=
s for nested&nbsp;</div><div>classes as proposed in this RFC. There is n=
o way for anyone except for&nbsp;</div><div>the author of the class `A` =
to create a property with the fully&nbsp;</div><div>qualified name `A::$=
foo`. Granted, properties could be inherited from a&nbsp;</div><div>pare=
nt class and might thus cause collisions with a private property in&nbsp=
;</div><div>a subclass. However the same collision would happen if the c=
hild class&nbsp;</div><div>would already have a public property of the s=
ame name. Importantly, the&nbsp;</div><div>child class could just rename=
 its private property without any effect on&nbsp;</div><div>any other cl=
ass and also parent classes can introduce private properties&nbsp;</div>=
<div>without any effect on any other class.</div><div><br></div><div>Thi=
s is difference for nested classes as proposed in this RFC, since the&nb=
sp;</div><div>namespace of nested classes is shared with the namespace o=
f regular&nbsp;</div><div>classes and the namespace of regular classes i=
s not =E2=80=9Cclosed off=E2=80=9D for&nbsp;</div><div>addition after th=
e initial declaration.</div><div><br></div><div>&gt; It's also not a new=
 problem: PHP doesn't enforce a file and directory layout, and libraries=
 can and do define things "inside" each other's namespaces. When declari=
ng a class, you have to be aware of whether a class with the same fully-=
qualified name has been, or will be, declared in another file.</div><div=
><br></div><div>This is correct, but all these other classes that could =
conflict are&nbsp;</div><div>part of the *public API* of a library. But =
now with private nested&nbsp;</div><div>classes I would also be aware of=
 the private part of a library to avoid&nbsp;</div><div>conflicts.</div>=
<div><br></div><div>Best regards</div><div>Tim D=C3=BCsterhus</div><div>=
<br></div></blockquote><div><br></div><div>Hi Tim,</div><div><br></div><=
div>I think these are fundamental problems (if they are a problem at all=
) with how PHP currently does namespaces and names. I'm curious if you w=
ould vote "no" for namespace visibility as well? While not intended to b=
e used as "modules," this has many of the same constraints and effects t=
hat full namespace visibility would have=E2=80=94including the same prob=
lems you allude to here.</div><div><br></div><div>As I was going to work=
 on short syntax classes next if this one passed, as well as namespace v=
isibility/modules after that (regardless of this RFC passing), I'd reall=
y like to know if this behavior is that big of an issue. If so, it is pr=
obably not worth pursuing namespace visibility if this RFC fails.</div><=
div><br></div><div>For everyone else who voted "no"; I would sincerely l=
ove to know the reason. Even if you just email me directly; it would rea=
lly help me understand what can be improved in any future RFCs.</div><di=
v><br></div><div id=3D"sig121229152">=E2=80=94 Rob</div></body></html>
--91f9711e698a46c49d6bea39f6933770--