Re: Module or Class Visibility, Season 2

On 14 May 2025 14:24:57 BST, Michael Morris <tendoaki@gmail.com> wrote: >Well, it's what Go calls "modules". It's confusing because I was being >truthful, not snarky, when I said "Ask 10 programmers for the definition of >module and expect 12 answers." I'm self trained, so I expect to get my >terms wrong from time to time. But I know enough to identify problems and >needs and I've tried to be clear on that. 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*. 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. 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" $client1 and $client2 are instances of different classes, with the same name! How does "instanceof" behave? What about "get_class"? What if you serialize and unserialize? I think if you changed the language enough that those questions didn't matter, it would be a language fork on the scale of Python 2 to 3, or even Perl 5 to Raku (originally called "Perl 6"). Every single application and library would have to be rewritten to use the new concept of what a class is. And most of them would get absolutely no benefit, because they *want* to reference the same version of a class everywhere in the application. 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. Regards, Rowan Tommins [IMSoP]