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
