Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127250
Feedback-ID: id5114917:Fastmail
Date: Wed, 30 Apr 2025 11:51:55 +0100
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Re: RFC: Nested Classes
User-Agent: K-9 Mail for Android
In-Reply-To: <213a8711-adbc-42b7-bcb8-86e64cb22cf2@bastelstu.be>
References: <aae32397-0567-417f-adbe-6b663d5c49ae@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> <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>
Message-ID: <5A723310-1AB6-4D4A-88CC-52EC4E81AE5C@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 29 April 2025 19:50:52 BST, "Tim D=C3=BCsterhus" <tim@bastelstu=2Ebe> w=
rote:
>I'm saying that I cannot add a private class Foo\Bar inside of the class =
Foo without checking whether a class Bar inside a namespace Foo already exi=
sts, since both would conflict=2E Even more problematic: I can't add a clas=
s Bar inside of namespace Foo, without needing to check the source code of =
class Foo to determine whether there is a private class Bar that I have no =
business of knowing that it exists=2E


I think you are insisting on a different definition of "private" for neste=
d classes than exists anywhere else in the language, and one that I've not =
seen evidence of in any other similar language either=2E It seems you want =
members to be "hidden", such that you can't even know they exist=2E=20

More specifically, you want their *fully-qualified name* to somehow be ava=
ilable for reuse=2E That's not how private members of a class work - method=
s A::foo() and B::foo() have different fully-qualified names, as do propert=
ies A::$foo and B::$foo, regardless of visibility and inheritance=2E It's n=
ot how "namespace private", "module private", or "file private" classes wou=
ld naturally work, because they all would need to be referenceable with ful=
ly-qualified names within the scope where they were visible=2E=20

It's also not a new problem: PHP doesn't enforce a file and directory layo=
ut, and libraries can and do define things "inside" each other's namespaces=
=2E When declaring a class, you have to be aware of whether a class with th=
e same fully-qualified name has been, or will be, declared in another file=
=2E

There is a challenge in any feature that encourages multiple definitions i=
n one file, that new conventions are needed to know at a glance when that i=
s in use, because we have become accustomed to the (Java-inspired?) one-cla=
ss-per-file convention=2E That's not about *hiding* things, though, because=
 those multiple definitions might be public; nor is it unique to this propo=
sal - it comes up with function autoloading, typedefs, and many more=2E


>And when I'm forced to always verify whether my private classes conflict =
with something, then nested classes do not provide a measurable value-add o=
ver a =E2=80=9Cregular class=E2=80=9D in a namespace matching the parent cl=
ass' class name that is marked `@internal`=2E


The value-add is 1) that they enforce the visibility at the language level=
, and 2) that they allow a concise syntax for declaring a set of closely re=
lated classes=2E

I'm not wholly convinced that they do that better than "file private" or "=
module private", but I don't agree that "class hiding" is essential, or eve=
n particularly desirable=2E


Rowan Tommins
[IMSoP]