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
