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 <[email protected]> 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