Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127572
Precedence: bulk
MIME-Version: 1.0
References: <CADK1yXKg1xpneLs3vJ=nUAAGaVuBhqkEMgbBVaYfcBfQL2vkDg@mail.gmail.com>
 <10D95B6E-094B-4EAE-A18A-AF6B795CB352@rwec.co.uk> <2adbff61-5e11-4d39-ab5c-d7950a4550a6@app.fastmail.com>
 <79E7FA26-2F5A-470C-B1DF-12CC46A08FE5@rwec.co.uk> <cda01760-9f0e-48e4-801d-f436243e088c@app.fastmail.com>
 <1c6dcd84-9016-48e1-971f-de7749cbdce8@rwec.co.uk> <D01184DD-EA70-41A4-9306-E09F904042C5@garsi.de>
 <a98a83fd-5486-4713-984b-d4fdb111d85d@app.fastmail.com> <44F59416-3922-4AF4-881A-C64F2C4E9345@rwec.co.uk>
 <7F11844A-A98C-4843-BC94-815FBCD2B73F@garsi.de> <7840468C-F60C-4A44-AE40-16F9007EF428@rwec.co.uk>
 <160E9B1D-9AF6-479B-A628-A73C618D7C1B@garsi.de> <CAEUnE0eYuvQWMJ6cffhyT-=A-Tj4WiknfALE0jfV=OHoqKMSsw@mail.gmail.com>
 <cb08e628-72ad-4ad9-8ead-bcb0cbcbfbd1@app.fastmail.com> <2c5c241c-bd05-4200-b6ee-e94c8ab0db1b@rwec.co.uk>
 <a182595e-77a1-42f0-b62e-628fd3dbbd62@app.fastmail.com> <894DC5D3-3CDD-479F-BAC1-70EE1AE0C5E2@rwec.co.uk>
 <5eb5b1b4-7cb2-4a2b-afdd-ad3e83ae856d@app.fastmail.com> <57d08124-fb6a-4e0b-8d42-bdb645571b13@rwec.co.uk>
 <b7eefb0d-778d-480a-a8b6-1bf5fcf69877@app.fastmail.com>
In-Reply-To: <b7eefb0d-778d-480a-a8b6-1bf5fcf69877@app.fastmail.com>
Date: Tue, 3 Jun 2025 16:18:45 -0400
Message-ID: <CAEUnE0dDXEzspUEZt6_ht15orUVMaDBHXHXjb-vUNFRXAAGq4Q@mail.gmail.com>
Subject: Re: [PHP-DEV] Module or Class Visibility, Season 2
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000000eb9b80636b09712"
From: tendoaki@gmail.com (Michael Morris)

--0000000000000eb9b80636b09712
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Jun 2, 2025 at 10:40=E2=80=AFPM Larry Garfield <larry@garfieldtech.=
com>
wrote:

> On Mon, Jun 2, 2025, at 3:28 PM, Rowan Tommins [IMSoP] wrote:
> > On 02/06/2025 17:57, Larry Garfield wrote:
> >> Well, now you're talking about something with a totally separate
> compile step, which is not what Michael seemed to be describing at all.
> But it seems like that would be necessary.
> >
> >
> > There's definitely some crossed wires somewhere. I deliberately left
> > the mechanics vague in that last message, and certainly didn't mention
> > any specific compiler steps. I'm a bit lost which part you think is
> > "not what Michael seemed to be describing".
> >
> >
> >
> > Picking completely at random, a file in Monolog has these lines in:
> >
> > namespace Monolog\Handler;
> > ...
> > use Monolog\Utils;
> > ...
> > class StreamHandler extends AbstractProcessingHandler {
> > ...
> > $this->url =3D Utils::canonicalizePath($stream);
> >
> >
> >
> > My understanding is that our goal is to allow two slightly different
> > copies of that file to be included at the same time. As far as I know,
> > there have been two descriptions of how that would work:
>
> This is what I was getting at.  As I understand what Michael's examples
> have described, it allows pulling a different version of one or more file=
s
> into some kind of container/special namespace/thingiewhatsit, at runtime.
>

At some point that could be a fair assessment of what I was saying. I'm
coming around to Rowain's container view though, enough to start thinking
of this as container modules.  I don't want to get in the weeds of how the
files for a container module get set up by whatever package manager is
chosen as that's a massive problem to solve in its own right.  For now I
would like to focus on this idea of having a container that can do whatever
it needs to do without affecting the code that started it in any way.
Avoiding the enormous code/file duplication that will result from this is a
separate, later problem and admittedly might not be solvable. But having a
container mechanism, even if it isn't optimized, would be healthier than
having plugins that carry their own Stauss monkey-typed copies of the
libraries they need even if those are several minor versions behind (which
should be compatible if the author obeys semantic versioning).

--0000000000000eb9b80636b09712
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 Mon, Jun 2, =
2025 at 10:40=E2=80=AFPM Larry Garfield &lt;<a href=3D"mailto:larry@garfiel=
dtech.com">larry@garfieldtech.com</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">On Mon, Jun 2, 2025, at 3:28 PM, Rowan Tom=
mins [IMSoP] wrote:<br>
&gt; On 02/06/2025 17:57, Larry Garfield wrote:<br>
&gt;&gt; Well, now you&#39;re talking about something with a totally separa=
te compile step, which is not what Michael seemed to be describing at all.=
=C2=A0 But it seems like that would be necessary.=C2=A0 <br>
&gt;<br>
&gt;<br>
&gt; There&#39;s definitely some crossed wires somewhere. I deliberately le=
ft <br>
&gt; the mechanics vague in that last message, and certainly didn&#39;t men=
tion <br>
&gt; any specific compiler steps. I&#39;m a bit lost which part you think i=
s <br>
&gt; &quot;not what Michael seemed to be describing&quot;.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; Picking completely at random, a file in Monolog has these lines in:<br=
>
&gt;<br>
&gt; namespace Monolog\Handler;<br>
&gt; ...<br>
&gt; use Monolog\Utils;<br>
&gt; ...<br>
&gt; class StreamHandler extends AbstractProcessingHandler {<br>
&gt; ...<br>
&gt; $this-&gt;url =3D Utils::canonicalizePath($stream);<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; My understanding is that our goal is to allow two slightly different <=
br>
&gt; copies of that file to be included at the same time. As far as I know,=
 <br>
&gt; there have been two descriptions of how that would work:<br>
<br>
This is what I was getting at.=C2=A0 As I understand what Michael&#39;s exa=
mples have described, it allows pulling a different version of one or more =
files into some kind of container/special namespace/thingiewhatsit, at runt=
ime.<br></blockquote><div><br></div><div>At some point that could be a fair=
 assessment of what I was saying. I&#39;m coming around to Rowain&#39;s con=
tainer view though, enough to start thinking of this as container modules.=
=C2=A0 I don&#39;t want to get in the weeds of how the files for a containe=
r module get set up by whatever package manager is chosen as that&#39;s a m=
assive problem to solve in its own right.=C2=A0 For now I would like to foc=
us on this idea of having a container that can do whatever it needs to do w=
ithout affecting the code that started it in any way. Avoiding the enormous=
 code/file duplication that will result from this is a separate, later prob=
lem and admittedly might not be solvable. But having a container mechanism,=
 even if it isn&#39;t optimized, would be healthier than having plugins tha=
t carry their own Stauss monkey-typed copies of the libraries they need eve=
n if those are several minor versions behind (which should be compatible if=
 the author obeys semantic versioning).</div><div><br></div><div>=C2=A0</di=
v></div></div>

--0000000000000eb9b80636b09712--