On Wed, Jul 16, 2025, at 10:44 AM, Deleu wrote: > On Wed, Jul 16, 2025 at 3:49 AM Rob Landers <rob@bottled.codes> wrote: >> __ >> >> Why I haven't proposed it as a separate RFC: with PSR-4 being so popular, >> nobody is going to write one-line files to take advantage of this. Thus, >> when I was going to revisit nested classes later this year (after all the >> release shenanigans and some personal issues), I was planning to add this >> feature to the nested class v2 RFC (again). A lot of feedback I got on >> nested classes was "when would I use this?" -- and I suspect that would be a >> lot of the feedback you'd get here (see: PSR-4). I'm more convinced than >> ever that short constructors and nested classes create a chicken-and-egg >> problem. They only really make sense together; at least with our current >> coding conventions and standards. It will create a longer discussion period, >> but that's fine, IMHO. >> >> If you'd like to continue with this RFC, I'd love to discuss it further with >> you and help you out. I believe it is a bit more than "just" syntax sugar, >> but I'd have to dig out my records implementation. >> >> — Rob > > I remember PHP from ~2000's and PSR-4 and Composer were probably one of > the biggest improvements to the ecosystem. However, I feel like a "2.0" > version is long overdue. I have participated in some internals > discussions that point out a fact from the other direction: PHP makes > no imposition about file structure. 1-class-per-file is strictly a > PSR-4 implementation of a custom autoloader which we have gotten used > to for so long. I would really love to be able to declare small related > classes/interfaces in a single file much like we can do with > Typescript, but the current state of PHP "register your autoloader > however you would like it" vs the current state of the community "PSR-4 > is THE standard", we end up between a rock and a hard place. I don't > particularly enjoy nested classes and how the syntax and its contexts > get involved. Sure it would be nice to have private classes, but it > gets quite cumbersome to have to do it while nesting classes within > classes.
I will reiterate what I have said many times in the context of function autoloading: The only autoloader that really matters in practice is Composer. Composer supports "front-load this list of files". You can put whatever you want in there. We have an opcache. I am really not concerned about the cost of front-loading a bunch of small functions or classes. If you're using React, FrankenPHP, or many of the other new-wave run models, you have a persistent process anyway so just expect everything to get loaded. So having a "dto.php" or "classes.php" file that Composer just front-loads on every request that contains a bunch of one-liner class definitions (or functions, or whatever) is perfectly fine, and works today. The only thing that would need to change is for SA tools (mostly PHPStorm) to be less whiny if they see a class that doesn't match its file name. But I am quite confident JetBrains can figure out how to do that. In short: This is not a real problem. There's no need for us to make it one. --Larry Garfield
