On Wed, Jul 16, 2025 at 12:59 PM Larry Garfield <la...@garfieldtech.com> wrote:
> > 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 > This works for me, but if I do it alone on my projects, it's just an invitation for someone else to call it legacy garbate and undo it. Perhaps I'm alone in this bubble and everyone else is already doing it, but from where I'm standing that's just a recipe for people to raise their eyebrows and feel confused. For better or worse, Composer "files" feature is nearly as flexible as PHP autoloader. I could make what I want work with either of them, but if every project has a different approach on how to do it, we're slightly back to 2000's PHP or we're in 2020's Node. Maybe I brought this upon myself by mentioning Typescript's capabilities, but to be more precise, I do it (and love it) while working on Single File Components in VueJS, which is not a language-wide standard, but in its own corner it is a comprehensive and well established standard. Should I have a single `classes.php` on my Composer files and put everything in there? Should it be one file per module? If someone on my team copy/paste a file like that into another module/project/repository/whatever and suddenly they're seeing "PHP Error class not found" for 2 hours because this is such an uncommon error in modern PHP, is it his mistake for not understanding it or is it mine for creating something far away from obvious? The blessing and the curse of PSR-4 is that it spoiled us (or maybe just me?) to: - never think about `require/include` - never think about composer.json - never think about how classes/interfaces/traits are located - IDEs will auto-import stuff so I don't even need to think about `use` statement - I don't know how to debug "Class not found" issues because the last time I saw an error like this was 5 years ago when I was trying to mess up with custom autoload capabilities in order to declare multiple symbols in a single file. Maybe I'm alone in it and then it's fine for it to be just my problem. I'm sharing here in case it's also someone else's problem and we can do something about it. But please don't tell me it's not a real problem. -- Marco Deleu
