Re: Module or Class Visibility, Season 2
On 14 May 2025 14:24:57 BST, Michael Morris <[email protected]> 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]
Thread (13 messages)