On Wed, Jul 16, 2025, at 17:44, 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 won’t comment on the composer stuff or autoloading for that matter. But to your point about nested classes – well, the entire point of nested classes was to make it easy for encapsulation:
class FooSelector {
public function byId($id): array { /* select by Id / }
class AsAdmin extends FooSelector {
public function byId($id): array { / select by Id */ }
}
}
$selector = $isAdmin ? new FooSelector\AsAdmin : new FooSelector;
But where it really starts to get useful is when you can rewrite a return by array, into a simple object:
class FooSelector {
class Foo(int $id, string $bar);
public function byId($id): Foo { }
}
When working in established code, we very rarely write new classes when compared to greenfield systems, where you have to write every new class (data objects, services, controllers, repositories, etc). In greenfield php projects, you often reach for an array until you need to create a proper class. Instead of reaching for an array, or writing out an entire file + boilerplate class, you can just write a short, tightly scoped class… much like we used to do back before PSR-4. If you recall back then, we’d often put it in the same file because we always knew that FooSelector would always be included before you could get a Foo. (and yeah, it was a time bomb; it was only a matter of time before someone would create a Foo before they created a FooSelector and it would crash)
class Foo { /* */ }
class FooSelector { /* */ }
If you ever wanted to migrate it to a proper class, you’d just create a folder (FooSelector) and copy/paste the class into a new file and keep PSR-4 working just fine. In other words, trying to create a FooSelector\Foo when Foo was nested, would properly autoload the correct file.
Nested classes v2 won’t include visibility. I think that just complicated things too much.
But yes, in established code bases, they probably don’t make as much sense, but that was the main problem I was trying to solve: the annoyance of choosing between an array – or the boilerplate of creating a new class just to hold a few fields.
On the other hand, we can see from constructor property promotion that these little syntax sugar can be such a massive improvement to cognitive load, readability, writability, etc. I would really love to have something much like this RFC even if at first I need to do it as a one-line-per-file. To me, the more interesting chicken-egg problem to address is whether PHP needs to provide some change to symbols, namespaces, autoloader or if the community needs to expand PSR-4 in a way that allow us to not reject this RFC on the basis of “PSR-4 will drastically limit syntax sugar improvements”.
–
Marco Deleu
I’d also love to see this get implemented and I’ve offered to help as much as I can.
— Rob