Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127183
Message-ID: <158a5d7c-8ef6-4b5f-b8ef-593879a7a896@bastelstu.be>
Date: Thu, 24 Apr 2025 16:31:44 +0200
Precedence: bulk
MIME-Version: 1.0
Subject: Re: [PHP-DEV] Re: RFC: Nested Classes
To: Rob Landers <rob@bottled.codes>, internals@lists.php.net
References: <aae32397-0567-417f-adbe-6b663d5c49ae@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>
 <706e22d7-94eb-44bd-a280-f629ba93b630@app.fastmail.com>
 <03a5b9a8-9fe1-4656-ab04-dd58669488b3@app.fastmail.com>
Content-Language: en-US
In-Reply-To: <03a5b9a8-9fe1-4656-ab04-dd58669488b3@app.fastmail.com>
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/20/25 15:43, Rob Landers wrote:
> As it seems that discussion has mostly died down, I'd like to put this towards a vote starting on May 1, 2025.

Unfortunately I did not have the time to follow the discussion after 
mid-March, so this might or might not have been discussed already. I 
just skimmed the RFC and a big issue from my PoV is the interaction of 
private nested classes and the shared namespace.

All existing private symbols in PHP are “invisible” or “non-existent” 
from the outside for all intents and purposes. As an example, it is 
possible to add a new private method to a class, without having an 
effect on child classes that already defined a method with the same name.

To my understanding this is different with private nested classes. A 
private nested class will “block the name” in the global class table, 
leading to naming conflicts with something the user shouldn't even know 
exists (because it's private).

This is a reason for me to vote against the RFC and a reason why I 
preferred Ilija's “file private” classes that are much simpler to reason 
about.

Best regards
Tim Düsterhus