Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127282
Message-ID: <681845d2-ff1e-4ab8-97b2-50fecfdcb62b@bastelstu.be>
Date: Sun, 4 May 2025 15:52:23 +0200
Precedence: bulk
MIME-Version: 1.0
Subject: Re: [PHP-DEV] Re: RFC: Nested Classes
To: "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>, internals@lists.php.net
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>
Content-Language: en-US
In-Reply-To: <5A723310-1AB6-4D4A-88CC-52EC4E81AE5C@rwec.co.uk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

Hi

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 exist.

No, I don't think I'm using a different definition of "private" for 
nested classes.

> 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 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 fully-qualified names within the scope where they were visible.
The difference is that for private class members there is no chance of 
name collisions of the "fully-qualified" name, but there is for nested 
classes as proposed in this RFC. There is no way for anyone except for 
the author of the class `A` to create a property with the fully 
qualified name `A::$foo`. Granted, properties could be inherited from a 
parent class and might thus cause collisions with a private property in 
a subclass. However the same collision would happen if the child class 
would already have a public property of the same name. Importantly, the 
child class could just rename its private property without any effect on 
any other class and also parent classes can introduce private properties 
without any effect on any other class.

This is difference for nested classes as proposed in this RFC, since the 
namespace of nested classes is shared with the namespace of regular 
classes and the namespace of regular classes is not “closed off” for 
addition after the initial declaration.

> 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 declaring 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.

This is correct, but all these other classes that could conflict are 
part of the *public API* of a library. But now with private nested 
classes I would also be aware of the private part of a library to avoid 
conflicts.

Best regards
Tim Düsterhus