On 11 June 2026 01:23:29 BST, Morgan <[email protected]> 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]

Reply via email to