Re: Two-step creation for PHP modules

On 11 June 2026 01:23:29 BST, Morgan <Weedpacket@varteg.nz> wrote: >On 2026-06-11 03:24, Rowan Tommins [IMSoP] wrote: > >> >> Take Guzzle, for example; it has 43 source files within a specific namespace root. A >> handful of those are marked "@internal", and a way for PHP to error if users reference >> them directly would be useful. Some users end up wanting conflicting versions of Guzzle >> simultaneously, e.g. in different WordPress plugins; so some way of isolating or rewriting class >> names (and all their references) would be useful. >> >> There are not 43 separate "modules", and the maintainers of Guzzle aren't >> going to combine all of them into one file. Defining a single package with multiple files is not a >> stretch goal, it's the only plausible starting point. >> >Just throwing this out, but couldn't the "module file" - the one that users bring >into their project and the one that exports what it's declared to export - delegate the >definitions of the functions etc. both public and private to other files? > >I mean, PHP already _has_ an "include" statement... It could, but that just moves the problem: right now, I can use any class in Guzzle from anywhere in my application as long as I configure the right autoloader. I can pass objects from Guzzle into and out of other libraries, and they all agree on what each class name means. Having to write an "import" statement means I have to be conscious of where I "start" using Guzzle. If every import of the library creates a magically prefixed copy of the entire library, I'm not even clear how I'd refer to different Guzzle classes in different files of my application; let alone how libraries could pass those objects in and out and agree that they were the same class. Namespace visibility is really really easy; as if file visibility, if you want that. Usable namespace rewriting is much more difficult, but doing it per file makes it harder, not easier. As Larry said, just stop trying to make file==module work. It's not the right approach for PHP. Rowan Tommins [IMSoP]