Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126922
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Mon, 24 Mar 2025 11:08:47 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <21719220-4b27-43cc-b387-ff803419de59@app.fastmail.com>
In-Reply-To: <efcac45a-60ac-4145-b012-72d5fef0090c@app.fastmail.com>
References: <aae32397-0567-417f-adbe-6b663d5c49ae@app.fastmail.com>
 <CAO__Xv4END_NsATOGSnCArGuP_UmSpMxSMsSNPsQZnLooOWTsQ@mail.gmail.com>
 <3e4ba7ea-a154-452d-abfc-05ef1322fade@app.fastmail.com>
 <AM8P250MB0170DE2A7E1AEE1FE1ED1F7CE2DF2@AM8P250MB0170.EURP250.PROD.OUTLOOK.COM>
 <782d76d9-711a-4cee-ae0e-fe0d69973f53@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>
Subject: Re: [PHP-DEV] RFC: short and inner classes
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
From: larry@garfieldtech.com ("Larry Garfield")

On Mon, Mar 24, 2025, at 3:47 AM, Rob Landers wrote:

> On Sun, Mar 23, 2025, at 16:17, Larry Garfield wrote:

>> I've been following this thread with interest, and at the moment I'm honestly undecided.  I certainly see the use cases for this functionality (whatever it gets named), but as a practical matter it sounds like it introduces a lot of extra clunk and complexity.  And it seems like the use cases could be addressed as well with either fileprivate or module-private.  (The former being considerably less work.)
>> 
>> So, how would nested classes compare to fileprivate, in terms of ability to solve the problem space?  As I understand it, the goal is:
>> 
>> 1. Classes that can be instantiated only by the class that uses them.
>> 2. But can be returned from that class to a caller and reused as appropriate.
>> 
>> The autoloading question (loading a whole file for just an implementation detail value object) is not one that carries much weight for me, as that's a user-space question, not an engine question.  (Nothing in PHP itself says you cannot put 20 3 line classes or enums together in one file.  It's just PSR-4 that says not go. Even composer would allow it if configured properly)  So how would the less-complicated alternative compare?
>> 
>> --Larry Garfield
>
> Hey Larry,
>
> I think file-private would/could be useful, but that only limits you to 
> a "private" scope, which severely hampers what you can do with it. If 
> we went with "module-private" (rhetorical question: what is a module?), 
> but then you wouldn't be able to have "private" scope.

When I say module scope, I'm referring to something along the lines that Arnaud and I were exploring a while back.  tldr, "cluster of files with a common namespace root, which can get loaded together."  It was mostly about performance, but did offer module-private as well, with some nice potential.  At the moment it's stalled out on "there's nasty hard edge cases and we're not sure if it's worth it" concerns.

Concept brain dump here: https://github.com/Crell/php-rfcs/blob/master/modules/spec-brainstorm.md
Code exploration from Arnaud here: https://github.com/arnaud-lb/php-src/pull/10

Still well short of RFC state, of course, but provided for context.

> With nested/inner classes, for example, you can put a protected class 
> on a class or interface and access it only from those that use it, 
> regardless of what file or "module" (namespace?) they are in; the logic 
> can be encapsulated to where it is used, not where it is defined.
>
> interface Shipment {
>   protected class Items {}
>   public readonly class Destination {}
>   function deliver(self:>Destination $destination);
> }
>
> class InternationalShipment implements Shipment {
>   private function handle(Shipment:>Items $items) {}
>
>   public function deliver(Shipment:>Destination $destination) {}
> }

In this case, I am not seeing what the nesting gets you.  Making Destination a normal class doesn't hurt anything here, does it?

> However, you can use private nested/inner classes to encapsulate the 
> logic to where it is defined instead, like file-private would give you.
>
> The goal here isn't to only to reduce "namespace pollution" but also to 
> encapsulate related logic integrally connected to the outer class's 
> behavior. Since you've referenced Kotlin a number of times, I assume 
> you are familiar with the concept of nested classes there? This is 
> extremely similar.

My short foray into Kotlin did not include nested classes, so I cannot speak to them other than knowing they exist.

--Larry Garfield