Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126915
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Sun, 23 Mar 2025 10:17:30 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <0db0cce1-c2da-4298-a7a0-c9c9c82ab498@app.fastmail.com>
In-Reply-To: <2935d0e2-ddc4-447c-ab37-c9b7337b8b60@app.fastmail.com>
References: <aae32397-0567-417f-adbe-6b663d5c49ae@app.fastmail.com>
 <2935d0e2-ddc4-447c-ab37-c9b7337b8b60@app.fastmail.com>
Subject: Re: [PHP-DEV] Re: RFC: short and inner classes
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Wed, Mar 12, 2025, at 5:10 AM, Rob Landers wrote:

> Hello internals,
>
> I've made some major updates to the text of the RFC to clarify=20
> behaviors and revisited the implementation (which is still under=20
> development, though I hope to have a draft by the end of this weekend)=
.=20
> Here's a broad overview of what has changed in inner classes:
>
> - Accessing inner classes is done via a new token: ":>" instead of "::=
".
> - Inner classes may now be infinitely nested.
> - Inner classes may be declared `abstract`.
> - Documented changes to ReflectionClass.
> - Usage of `static` to refer to inner classes is restricted to prevent=20
> accidental violations of LSP.
>
> Otherwise, there are not any big changes, but a lot of time was spent=20
> clarifying behavior and expanding on the reasoning for those decisions=20
> in the RFC itself.
>
> =E2=80=94 Rob

I've been following this thread with interest, and at the moment I'm hon=
estly undecided.  I certainly see the use cases for this functionality (=
whatever it gets named), but as a practical matter it sounds like it int=
roduces a lot of extra clunk and complexity.  And it seems like the use =
cases could be addressed as well with either fileprivate or module-priva=
te.  (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 appropr=
iate.

The autoloading question (loading a whole file for just an implementatio=
n detail value object) is not one that carries much weight for me, as th=
at's a user-space question, not an engine question.  (Nothing in PHP its=
elf 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 conf=
igured properly)  So how would the less-complicated alternative compare?

--Larry Garfield