Re: Two-step creation for PHP modules

On Tue, Jun 9, 2026, at 11:39 AM, Alex Rock wrote: >> First, what is the problem you want to solve? > > The main problems that PHP modules solve are the following: > > - Libraries can finally isolate code completely, and not only in > private class methods, but they can isolate entire structures, and can > even isolate a sub-library > - Since all modules internally contain a hashed-prefix version of all > their definitions, two versions of the same library can coexist, since > a module hash is unique based on its file path and contents (I should > have made it explicit that the module prefix is hashed based on file > contents & path, to ensure uniqueness) > > Many existing libraries could migrate parts of their internal > structures (the ones not supposed to be supported by their BC policy) > to modules with no impact on userland code. See, I don't think this is remotely true. Consider Serde. (My go-to example.) It contains dozens of class-likes. A typical serialization request is going to use 90% of them. Being able to front-load and link all of them without going through the autoloader every time sounds good! But... There is no way in hell that I'm moving dozens of classes into a single file. Multi-thousand-line files are frowned upon for a reason. In practice I don't really need most of them to be private. Maybe one, I dunno. So I simply wouldn't bother., meaning I wouldn't benefit from whatever performance optimizations we are able to add later. So this approach makes modules something usable ONLY by code bases that have lots of defined class-likes or functions that are "private", AND they're all very very small so that the resulting mega-file isn't too large for my IDE to open. That's a very, very small number of cases. I will reiterate what Rowan said above, and what I said the last time modules were discussed: module == file is absolutely a dead-end for PHP. It simply will not work in practice. Not because of PSR-4 like some people keep claiming, but because the resulting files would be just too damned big and unwieldy. Add to that, how do I write tests for the "private" classes? I should still be able to test those on their own, without having to go through the few public facing classes. If the tests are in a separate file... how do I do that? Let's stop trying to make module == file happen. It's not going to happen. --Larry Garfield