Re: Module or Class Visibility, Season 2

On Thu, May 15, 2025, at 10:35, Rob Landers wrote: > On Thu, May 15, 2025, at 10:11, Rowan Tommins [IMSoP] wrote: >> >> >> On 14 May 2025 22:27:32 BST, Rob Landers <rob@bottled.codes> wrote: >> > >> >As written, that simply isn't possible in PHP because there is only one class >> >allowed with a given name. Names of classes are global. I don't think this has to be the case, >> >though. Different languages take different approaches to this. For example, JavaScript allows each >> >module to "close over" its dependencies so each module can import its own version of >> >dependencies. >> >> I would say that JavaScript doesn't just *allow* this, as an added feature, it >> *requires* it, as a fundamental design decision: >> >> - In JavaScript, Python, etc, when you declare a function or class, you are creating an >> anonymous object, and assigning it to a local variable. Code reuse requires you to pass that object >> around. >> - In PHP, Java, C#, etc, when you declare a function or class, you are adding a permanent >> named item to a global list. Code reuse is about knowing the global names of things. >> >> It's worth noting that JavaScript didn't need to add *any* features to make NPM, >> Bower, etc work; everything they do is based on the fact that declarations are objects which can be >> passed around at will. >> >> That's why I don't think "JavaScript can do it" is relevant, because >> the *way* JavaScript does it is impossible in PHP. We're much better off looking at how *PHP* >> works, and what problems we're actually trying to solve. >> >> And that in turn is why I was reaching for Linux containers as an alternative analogy, to >> think about the problem without jumping to the wrong solution. >> >> Rowan Tommins >> [IMSoP] >> > > Hey Rowan, > > When working on nested classes, I did spend quite a bit of time tinkering with alternative > implementations. One of those implementations was having the ability for classes to have their own > class tables (both literally and emulated via name mangling) which would have allowed for classes to > have private classes that could share names with external classes. This turned out to be an utter > disaster of an idea for many reasons. Namely, PHP doesn't really have any native support for > shadowing names. Sure, there is aliasing via use statements, but that only works for classes outside > the current namespace. As long as we can guarantee that a module acts as a special namespace (under > the hood), the only potential for collisions will be in the module itself. > > All that is to say that I don't think comparing PHP to JavaScript is appropriate when > considering modules. JavaScript doesn't have types, so I can pass you an EpicStringV2 when > you're expecting an EpicStringV1, and as long as my EpicStringV2 has the right prototypical > behavior and data, it will work just fine. PHP is typed, and fairly strongly typed. There is > effectively no way to have multiple versions of the same type running around a codebase and pass > type checks. Changing this would be effectively impossible and probably unsound from a type-theory > perspective. > > — Rob Haha, I just reread your email and realized we're basically saying the same thing (I think?). — Rob