Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127304
Feedback-ID: id5114917:Fastmail
Message-ID: <1069dc6f-a19c-4210-8b8d-03e2efa7b17e@rwec.co.uk>
Date: Wed, 7 May 2025 18:21:08 +0100
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] Re: RFC: Nested Classes
To: internals@lists.php.net
References: <aae32397-0567-417f-adbe-6b663d5c49ae@app.fastmail.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>
 <91B29E1C-EA9D-4BF0-8D69-42B43820F574@rwec.co.uk>
 <4943d4f939e61a72b41f9edacbf8eeca@bastelstu.be>
Content-Language: en-GB
In-Reply-To: <4943d4f939e61a72b41f9edacbf8eeca@bastelstu.be>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")

On 07/05/2025 14:10, Tim Düsterhus wrote:
> And rewrite all references inside of `Foo` to `Foo$Bar` (using Java's 
> name mangling). This is effectively what Ilija's proposal for 
> file-private classes did: https://externals.io/message/126331#126337. 
> I think this would also be nicer on the autoloading impact. Since a 
> private class is not usable outside of its container class, it doesn't 
> make sense to attempt to autoload it individually, since to reference 
> it, the container class must already be loaded (which means the 
> private class is also already loaded). 


I agree that this would be possible; I disagree that it is essential, or 
that it has anything to do with consistency with the rest of the language.

I'm not even sure if it would be a good idea - it would mean having what 
appears to be a fully-qualified name actually "shadowed" by a completely 
unrelated definition within a particular scope. For example "\Foo\Bar" 
would still refer to "namespace Foo, class Bar" in most of the program, 
but "class Foo, nested class Bar" in the context of class Foo. If the 
visibility was changed to "public", the shadowing would instantly become 
a conflict anyway; and I can't picture how "protected" would work.


-- 
Rowan Tommins
[IMSoP]