On Wed, May 14, 2025 at 10:57 AM Rowan Tommins [IMSoP] <[email protected]>
wrote:
>
> I don't know much about Go, but at a glance it uses a similar model to
> JavaScript and Python where *classes don't have a universal name*, the
> names are always local. That's not a different kind of module, it's a
> fundamentally different *language design*.
>
>
That said, they call them modules. I'm not going to argue with them, what
do I know?
> If you want to use two different versions of Guzzle in the same
> application, the first problem you need to solve has nothing to do with
> require, or autoloading, or Phar files. The first problem you need to solve
> is that you now have two classes called \GuzzleHttp\Client, and that breaks
> a bunch of really fundamental assumptions.
Your fundamental assumption is that the different versions are loaded onto
the same symbol. Given the problems you outline yourself, why do that?
You see, PHP doesn't have a mechanism for symbol changing at compile time.
Everything loads onto the root. Does it *have* to be that way? Or can a
file compile onto a namespace, effectively prefixing that namespace.
>
>
> For example:
> - plugin1 uses Guzzle v5, runs "$client1 = new \GuzzleHttp\Client", and
> returns it to the main application
> - The main application passes $client1 to plugin2
> - plugin2 uses Guzzle v4
> plugin2 runs "$client2 = new \GuzzleHttp\Client"
>
If plugin 2 wants to use version 4 for whatever reason, why can't it load
it into \Plugin2\GuzzleHttpClient instead of onto the root??
This is what userland monkey-typers like Strauss do. It works, but there
are issues with this solution outlined elsewhere.
> That's why I think "containers" are the more useful comparison - you need
> some way to put not just plugin1 itself, but all the third-party code it
> calls, into some kind of sandbox, as though it was running in a separate
> process. If you can control what classes can go into and out of that
> sandbox, then in any piece of code, you don't end up with conflicting
> meanings for the same name - just as a Linux container can't open a network
> port directly on the host.
>
Container, module, block, package, plugin, domain, division, fraction,
lump, branch, sliver, splinter, constituent or whatever the hell else you
call it, I don't care. What I need is a way to manage package version
conflicts which arise in the real world when plugins get abandoned or when
coordinating having everyone change dependencies at the same time isn't
feasible.