Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127371
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Thu, 15 May 2025 10:35:12 +0200
To: internals@lists.php.net
Message-ID: <ca5c49c9-948a-48f0-8b94-86fea583fbc4@app.fastmail.com>
In-Reply-To: <B46C391D-2248-4E54-BFBE-2195FFB6A2A5@rwec.co.uk>
References: 
 <CADK1yXKg1xpneLs3vJ=nUAAGaVuBhqkEMgbBVaYfcBfQL2vkDg@mail.gmail.com>
 <3ae9a6ea-f135-472b-b2bf-e6cd6ebad299@app.fastmail.com>
 <CAEUnE0d8QADSYv+OJMEceN4hdJNcNy=-GLvW-ZoNqoi6_2Lhxw@mail.gmail.com>
 <9A26F72B-D0EF-414F-B193-BED3CAB26A0B@rwec.co.uk>
 <9f6a0d6e-27c3-4f77-aed6-e55147442b6f@app.fastmail.com>
 <B46C391D-2248-4E54-BFBE-2195FFB6A2A5@rwec.co.uk>
Subject: Re: [PHP-DEV] Module or Class Visibility, Season 2
Content-Type: multipart/alternative;
 boundary=a82d084f415f41f1954d555ea63673d5
From: rob@bottled.codes ("Rob Landers")

--a82d084f415f41f1954d555ea63673d5
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Thu, May 15, 2025, at 10:11, Rowan Tommins [IMSoP] wrote:
>=20
>=20
> 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 o=
ne 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 differe=
nt approaches to this. For example, JavaScript allows each module to "cl=
ose over" its dependencies so each module can import its own version of =
dependencies.
>=20
> I would say that JavaScript doesn't just *allow* this, as an added fea=
ture, it *requires* it, as a fundamental design decision:=20
>=20
> - In JavaScript, Python, etc, when you declare a function or class, yo=
u 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 kno=
wing the global names of things.=20
>=20
> 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 tha=
t declarations are objects which can be passed around at will.=20
>=20
> That's why I don't think "JavaScript can do it" is relevant, because t=
he *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 s=
olve.=20
>=20
> And that in turn is why I was reaching for Linux containers as an alte=
rnative analogy, to think about the problem without jumping to the wrong=
 solution.
>=20
> Rowan Tommins
> [IMSoP]
>=20

Hey Rowan,

When working on nested classes, I did spend quite a bit of time tinkerin=
g with alternative implementations. One of those implementations was hav=
ing the ability for classes to have their own class tables (both literal=
ly and emulated via name mangling) which would have allowed for classes =
to have private classes that could share names with external classes. Th=
is turned out to be an utter disaster of an idea for many reasons. Namel=
y, PHP doesn't really have any native support for shadowing names. Sure,=
 there is aliasing via use statements, but that only works for classes o=
utside the current namespace. As long as we can guarantee that a module =
acts as a special namespace (under the hood), the only potential for col=
lisions will be in the module itself.

All that is to say that I don't think comparing PHP to JavaScript is app=
ropriate when considering modules. JavaScript doesn't have types, so I c=
an pass you an EpicStringV2 when you're expecting an EpicStringV1, and a=
s long as my EpicStringV2 has the right prototypical behavior and data, =
it will work just fine. PHP is typed, and fairly strongly typed. There i=
s effectively no way to have multiple versions of the same type running =
around a codebase and pass type checks. Changing this would be effective=
ly impossible and probably unsound from a type-theory perspective.

=E2=80=94 Rob
--a82d084f415f41f1954d555ea63673d5
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title></head><body><div>On Thu, May =
15, 2025, at 10:11, Rowan Tommins [IMSoP] wrote:</div><blockquote type=3D=
"cite" id=3D"qt" style=3D""><div><br></div><div><br></div><div>On 14 May=
 2025 22:27:32 BST, Rob Landers &lt;<a href=3D"mailto:rob@bottled.codes"=
>rob@bottled.codes</a>&gt; wrote:</div><div>&gt;</div><div>&gt;As writte=
n, that simply isn't possible in PHP because there is only one class all=
owed with a given name. Names of classes are global. I don't think this =
has to be the case, though. Different languages take different approache=
s to this. For example, JavaScript allows each module to "close over" it=
s dependencies so each module can import its own version of dependencies=
.</div><div><br></div><div>I would say that JavaScript doesn't just *all=
ow* this, as an added feature, it *requires* it, as a fundamental design=
 decision:&nbsp;</div><div><br></div><div>- In JavaScript, Python, etc, =
when you declare a function or class, you are creating an anonymous obje=
ct, and assigning it to a local variable. Code reuse requires you to pas=
s that object around.</div><div>- In PHP, Java, C#, etc, when you declar=
e 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.&nbsp;</di=
v><div><br></div><div>It's worth noting that JavaScript didn't need to a=
dd *any* features to make NPM,&nbsp; Bower, etc work; everything they do=
 is based on the fact that declarations are objects which can be passed =
around at will.&nbsp;</div><div><br></div><div>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.&nbsp;</div><div><br><=
/div><div>And that in turn is why I was reaching for Linux containers as=
 an alternative analogy, to think about the problem without jumping to t=
he wrong solution.</div><div><br></div><div>Rowan Tommins</div><div>[IMS=
oP]</div><div><br></div></blockquote><div><br></div><div>Hey Rowan,</div=
><div><br></div><div>When working on nested classes, I did spend quite a=
 bit of time tinkering with alternative implementations. One of those im=
plementations 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 fo=
r many reasons. Namely, PHP doesn't really have any native support for s=
hadowing names. Sure, there is aliasing via use statements, but that onl=
y works for classes outside the current namespace. As long as we can gua=
rantee that a module acts as a special namespace (under the hood), the o=
nly potential for collisions will be in the module itself.</div><div><br=
></div><div>All that is to say that I don't think comparing PHP to JavaS=
cript is appropriate when considering modules. JavaScript doesn't have t=
ypes, so I can pass you an EpicStringV2 when you're expecting an EpicStr=
ingV1, and as long as my EpicStringV2 has the right prototypical behavio=
r and data, it will work just fine. PHP is typed, and fairly strongly ty=
ped. There is effectively no way to have multiple versions of the same t=
ype running around a codebase and pass type checks. Changing this would =
be effectively impossible and probably unsound from a type-theory perspe=
ctive.</div><div><br></div><div id=3D"sig121229152">=E2=80=94 Rob</div><=
/body></html>
--a82d084f415f41f1954d555ea63673d5--