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
> behaviors and revisited the implementation (which is still under
> development, though I hope to have a draft by the end of this weekend)..
> 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
> accidental violations of LSP.
>
> Otherwise, there are not any big changes, but a lot of time was spent
> clarifying behavior and expanding on the reasoning for those decisions
> in the RFC itself.
>
> — Rob
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