Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127361
Precedence: bulk
MIME-Version: 1.0
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>
In-Reply-To: <9A26F72B-D0EF-414F-B193-BED3CAB26A0B@rwec.co.uk>
Date: Wed, 14 May 2025 16:50:25 -0400
Message-ID: <CAEUnE0cJhbB6hmOqyRqXtt+bAXPoOnQozm9ONS9kdYcNB2_H3A@mail.gmail.com>
Subject: Re: [PHP-DEV] Module or Class Visibility, Season 2
To: internals@lists.php.net
Content-Type: multipart/alternative; boundary="0000000000008ded9706351eb3f2"
From: tendoaki@gmail.com (Michael Morris)

--0000000000008ded9706351eb3f2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, May 14, 2025 at 10:57=E2=80=AFAM Rowan Tommins [IMSoP] <imsop.php@r=
wec.co.uk>
wrote:

>
> 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
> fundamentally different *language design*.
>
>
That said, they call them modules. I'm not going to argue with them, what
do I know?


> 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 sol=
ve
> is that you now have two classes called \GuzzleHttp\Client, and that brea=
ks
> a bunch of really fundamental assumptions.


Your fundamental assumption is that the different versions are loaded onto
the same symbol.  Given the problems you outline yourself, why do that?

You see, PHP doesn't have a mechanism for symbol changing at compile time.
Everything loads onto the root.  Does it *have* to be that way? Or can a
file compile onto a namespace, effectively prefixing that namespace.


>
>
> For example:
> - 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"
>

If plugin 2 wants to use version 4 for whatever reason, why can't it load
it into \Plugin2\GuzzleHttpClient instead of onto the root??

This is what userland monkey-typers like Strauss do. It works, but there
are issues with this solution outlined elsewhere.


> That's why I think "containers" are the more useful comparison - 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 into 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 netwo=
rk
> port directly on the host.
>

Container, module, block, package, plugin, domain, division, fraction,
lump, branch, sliver, splinter, constituent or whatever the hell else you
call it, I don't care. What I need is a way to manage package version
conflicts which arise in the real world when plugins get abandoned or when
coordinating having everyone change dependencies at the same time isn't
feasible.

--0000000000008ded9706351eb3f2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote g=
mail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, May 14,=
 2025 at 10:57=E2=80=AFAM Rowan Tommins [IMSoP] &lt;<a href=3D"mailto:imsop=
.php@rwec.co.uk">imsop.php@rwec.co.uk</a>&gt; wrote:<br></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px soli=
d rgb(204,204,204);padding-left:1ex"><br>
I don&#39;t know much about Go, but at a glance it uses a similar model to =
JavaScript and Python where *classes don&#39;t have a universal name*, the =
names are always local. That&#39;s not a different kind of module, it&#39;s=
 a fundamentally different *language design*.<br>
<br></blockquote><div><br></div><div>That said, they call them modules. I&#=
39;m not going to argue with them, what do I know?</div><div>=C2=A0</div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft:1px solid rgb(204,204,204);padding-left:1ex">
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 au=
toloading, or Phar files. The first problem you need to solve is that you n=
ow have two classes called \GuzzleHttp\Client, and that breaks a bunch of r=
eally fundamental assumptions.</blockquote><div><br></div><div>Your fundame=
ntal assumption is that the different versions are loaded onto the same sym=
bol.=C2=A0 Given the problems you outline yourself, why do that?</div><div>=
<br></div><div>You see, PHP doesn&#39;t have a mechanism for symbol changin=
g at compile time. Everything loads onto the root.=C2=A0 Does it *have* to =
be that way? Or can a file compile onto a namespace, effectively prefixing =
that namespace.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi=
ng-left:1ex"> <br>
<br>
For example: <br>
- plugin1 uses Guzzle v5, runs &quot;$client1 =3D new \GuzzleHttp\Client&qu=
ot;, and returns it to the main application<br>
- The main application passes $client1 to plugin2<br>
- plugin2 uses Guzzle v4<br>
plugin2 runs &quot;$client2 =3D new \GuzzleHttp\Client&quot;<br></blockquot=
e><div><br></div><div>If plugin 2 wants to use version 4 for whatever reaso=
n, why can&#39;t it load it into \Plugin2\GuzzleHttpClient instead of onto =
the root??</div><div><br></div><div>This is what userland monkey-typers=C2=
=A0like Strauss do. It works, but there are issues with this solution outli=
ned elsewhere.</div><div><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex">
<br>
That&#39;s why I think &quot;containers&quot; are the more useful compariso=
n - you need some way to put not just plugin1 itself, but all the third-par=
ty 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 into and out of th=
at sandbox, then in any piece of code, you don&#39;t end up with conflictin=
g meanings for the same name - just as a Linux container can&#39;t open a n=
etwork port directly on the host.<br></blockquote><div><br></div><div>Conta=
iner, module, block, package, plugin, domain, division, fraction, lump, bra=
nch, sliver, splinter, constituent or whatever the hell else you call it, I=
 don&#39;t care. What I need is a way to manage package version conflicts w=
hich arise in the real world when plugins get abandoned or when coordinatin=
g having everyone change dependencies at the same time isn&#39;t feasible.<=
/div></div></div>

--0000000000008ded9706351eb3f2--