Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127363
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Wed, 14 May 2025 23:27:32 +0200
To: internals@lists.php.net
Message-ID: <9f6a0d6e-27c3-4f77-aed6-e55147442b6f@app.fastmail.com>
In-Reply-To: <9A26F72B-D0EF-414F-B193-BED3CAB26A0B@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>
Subject: Re: [PHP-DEV] Module or Class Visibility, Season 2
Content-Type: multipart/alternative;
 boundary=05eab717150b44caabef613c2400afb1
From: rob@bottled.codes ("Rob Landers")

--05eab717150b44caabef613c2400afb1
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Wed, May 14, 2025, at 16:57, Rowan Tommins [IMSoP] wrote:
>=20
>=20
> On 14 May 2025 14:24:57 BST, Michael Morris <tendoaki@gmail.com> 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 definit=
ion 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.
>=20
> 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 fu=
ndamentally different *language design*.

Go has some weird scoping, for sure. Everything is done by convention in=
stead of syntax. In other words, if you want to export a symbol, you cap=
italize it; otherwise, it is lower-cased and thus private to the module.=
 Then each directory is a module, and even in the same project, you cann=
ot access another lower-cased symbol from another directory -- er, modul=
e.

It is strange, and I don't think it translates to PHP. PHP is generally =
explicit via syntax over convention.

>=20
> If you want to use two different versions of Guzzle in the same applic=
ation, the first problem you need to solve has nothing to do with requir=
e, or autoloading, or Phar files. The first problem you need to solve is=
 that you now have two classes called \GuzzleHttp\Client, and that break=
s a bunch of really fundamental assumptions.=20

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 th=
ink 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 dep=
endencies. Originally, there wasn't even any deduplication, so you'd hav=
e 500 copies of left-pad or whatever. Then there is Go, which doesn't al=
low you to have multiple versions of modules. You get exactly one versio=
n, which is similar to how PHP currently works with composer by default.=
 However, with some massaging, you can "prefix" your imports so you get =
only your own version. I believe many WordPress plugins do this, so each=
 plugin can use their own version of things.

I'm fairly certain we can do a similar thing so that each module gets it=
s own unique 'namespace' in the class table such that two modules can de=
fine the same classes. So ModuleA and ModuleB can have Foo\Bar without c=
onflicting with one another. From the user's perspective, we can probabl=
y hide that technical detail from them but allow aliasing:

use module ModuleA; // import ModuleA's namespace into our current names=
pace for this file
use module ModuleB as Baz; // import ModuleB's namespace into our curren=
t namespace for this file, but with a prefix

Foo\Bar; // ModuleA\Foo\Bar
Baz\Foo\Bar; // ModuleB\Foo\Bar

I'm just spitballing syntax here, and I'm not suggesting it actually wor=
k like this, but I just want to illustrate that I think there are reason=
able ways to allow modules to have conflicting names.

> For example:=20
> - plugin1 uses Guzzle v5, runs "$client1 =3D new \GuzzleHttp\Client", =
and returns it to the main application
> - The main application passes $client1 to plugin2
> - plugin2 uses Guzzle v4
> plugin2 runs "$client2 =3D new \GuzzleHttp\Client"
>=20
> $client1 and $client2 are instances of different classes, with the sam=
e name! How does "instanceof" behave? What about "get_class"? What if yo=
u serialize and unserialize?

I'm of the opinion that the "names" of the module classes be distinct so=
 that humans (and deserializers) know it is from a module. Something lik=
e [ModuleA]\Foo\Bar.

>=20
> 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 e=
ven Perl 5 to Raku (originally called "Perl 6"). Every single applicatio=
n 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 th=
ey *want* to reference the same version of a class everywhere in the app=
lication.

I suspect the hard part will be defining the module in the first place. =
IE, the "package.json" or "go.mod" or whatever it gets called. As compos=
er isn't a part of the PHP project, I don't want to take it for granted,=
 but I also don't want to rely on it. That means each module may have to=
 define its own "loader" or somehow define what PHP files encompass the =
module. As I mentioned earlier, PHP doesn't usually operate by conventio=
n, though the community tends to force it to anyway (PSR-4 autoloading c=
omes to mind immediately); so we'd need something that is explicit but a=
utomatable so the community can implement conventions.

That's going to be the hard part.

>=20
> That's why I think "containers" are the more useful comparison - you n=
eed some way to put not just plugin1 itself, but all the third-party cod=
e it calls, into some kind of sandbox, as though it was running in a sep=
arate process. If you can control what classes can go into and out of th=
at 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 net=
work port directly on the host.

Exactly.

>=20
> Regards,
> Rowan Tommins
> [IMSoP]
>=20

=E2=80=94 Rob
--05eab717150b44caabef613c2400afb1
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title></head><body><div><br></div><d=
iv><br></div><div>On Wed, May 14, 2025, at 16:57, Rowan Tommins [IMSoP] =
wrote:</div><blockquote type=3D"cite" id=3D"qt" style=3D""><div><br></di=
v><div><br></div><div>On 14 May 2025 14:24:57 BST, Michael Morris &lt;<a=
 href=3D"mailto:tendoaki@gmail.com">tendoaki@gmail.com</a>&gt; wrote:</d=
iv><div>&gt;Well, it's what Go calls "modules". It's confusing because I=
 was being</div><div>&gt;truthful, not snarky, when I said "Ask 10 progr=
ammers for the definition of</div><div>&gt;module and expect 12 answers.=
"&nbsp; I'm self trained, so I expect to get my</div><div>&gt;terms wron=
g from time to time. But I know enough to identify problems and</div><di=
v>&gt;needs and I've tried to be clear on that.</div><div><br></div><div=
>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 n=
ames are always local. That's not a different kind of module, it's a fun=
damentally different *language design*.</div></blockquote><div><br></div=
><div>Go has some weird scoping, for sure. Everything is done by convent=
ion instead of syntax. In other words, if you want to export a symbol, y=
ou capitalize it; otherwise, it is lower-cased and thus private to the m=
odule. Then each directory is a module, and even in the same project, yo=
u cannot access another lower-cased symbol from another directory -- er,=
 module.</div><div><br></div><div>It is strange, and I don't think it tr=
anslates to PHP. PHP is generally explicit via syntax over convention.</=
div><div><br></div><blockquote type=3D"cite" id=3D"qt" style=3D""><div><=
br></div><div>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, an=
d that breaks a bunch of really fundamental assumptions.&nbsp;</div></bl=
ockquote><div><br></div><div>As written, that simply isn't possible in P=
HP because there is only one class allowed with a given name. Names of c=
lasses are global. I don't think this has to be the case, though. Differ=
ent 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. Originally, there wasn't even an=
y deduplication, so you'd have 500 copies of left-pad or whatever. Then =
there is Go, which doesn't allow you to have multiple versions of module=
s. You get exactly one version, which is similar to how PHP currently wo=
rks with composer by default. However, with some massaging, you can "pre=
fix" your imports so you get only your own version. I believe many WordP=
ress plugins do this, so each plugin can use their own version of things=
.</div><div><br></div><div>I'm fairly certain we can do a similar thing =
so that each module gets its own unique 'namespace' in the class table s=
uch that two modules can define the same classes. So ModuleA and ModuleB=
 can have Foo\Bar without conflicting with one another. From the user's =
perspective, we can probably hide that technical detail from them but al=
low aliasing:</div><div><br></div><div>use module ModuleA; // import Mod=
uleA's namespace into our current namespace for this file</div><div>use =
module ModuleB as Baz; // import ModuleB's namespace into our current na=
mespace for this file, but with a prefix</div><div><br></div><div>Foo\Ba=
r; // ModuleA\Foo\Bar</div><div>Baz\Foo\Bar; // ModuleB\Foo\Bar</div><di=
v><br></div><div>I'm just spitballing syntax here, and I'm not suggestin=
g it actually work like this, but I just want to illustrate that I think=
 there are reasonable ways to allow modules to have conflicting names.</=
div><div><br></div><blockquote type=3D"cite" id=3D"qt" style=3D""><div>F=
or example:&nbsp;</div><div>- plugin1 uses Guzzle v5, runs "$client1 =3D=
 new \GuzzleHttp\Client", and returns it to the main application</div><d=
iv>- The main application passes $client1 to plugin2</div><div>- plugin2=
 uses Guzzle v4</div><div>plugin2 runs "$client2 =3D new \GuzzleHttp\Cli=
ent"</div><div><br></div><div>$client1 and $client2 are instances of dif=
ferent classes, with the same name! How does "instanceof" behave? What a=
bout "get_class"? What if you serialize and unserialize?</div></blockquo=
te><div><br></div><div>I'm of the opinion that the "names" of the module=
 classes be distinct so that humans (and deserializers) know it is from =
a module. Something like [ModuleA]\Foo\Bar.</div><div><br></div><blockqu=
ote type=3D"cite" id=3D"qt" style=3D""><div><br></div><div>I think if yo=
u changed the language enough that those questions didn't matter, it wou=
ld be a language fork on the scale of Python 2 to 3, or even Perl 5 to R=
aku (originally called "Perl 6"). Every single application and library w=
ould 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 re=
ference the same version of a class everywhere in the application.</div>=
</blockquote><div><br></div><div>I suspect the hard part will be definin=
g the module in the first place. IE, the "package.json" or "go.mod" or w=
hatever it gets called. As composer isn't a part of the PHP project, I d=
on't want to take it for granted, but I also don't want to rely on it. T=
hat means each module may have to define its own "loader" or somehow def=
ine what PHP files encompass the module. As I mentioned earlier, PHP doe=
sn't usually operate by convention, though the community tends to force =
it to anyway (PSR-4 autoloading comes to mind immediately); so we'd need=
 something that is explicit but automatable so the community can impleme=
nt conventions.</div><div><br></div><div>That's going to be the hard par=
t.</div><div><br></div><blockquote type=3D"cite" id=3D"qt" style=3D""><d=
iv><br></div><div>That's why I think "containers" are the more useful co=
mparison - 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 in=
to 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.</div></blockquote><div><=
br></div><div>Exactly.</div><div><br></div><blockquote type=3D"cite" id=3D=
"qt" style=3D""><div><br></div><div>Regards,</div><div>Rowan Tommins</di=
v><div>[IMSoP]</div><div><br></div></blockquote><div><br></div><div id=3D=
"sig121229152">=E2=80=94 Rob</div></body></html>
--05eab717150b44caabef613c2400afb1--