Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127548
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Mon, 02 Jun 2025 21:38:58 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <b7eefb0d-778d-480a-a8b6-1bf5fcf69877@app.fastmail.com>
In-Reply-To: <57d08124-fb6a-4e0b-8d42-bdb645571b13@rwec.co.uk>
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>
Subject: Re: [PHP-DEV] Module or Class Visibility, Season 2
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
From: larry@garfieldtech.com ("Larry Garfield")

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 = 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 files into some kind of container/special namespace/thingiewhatsit, at runtime.

I fundamentally do not believe pulling arbitrary files into such a structure is wise, possible, or will achieve anything resembling the desired result, because *basically no application or library is single-file anymore*.  If you try to side-load an interface out of Monolog, but not a class that implements that interface, now what?  I don't even know what to expect to happen, other than "it will not work, at all."

The *only* way I can see for this to work is to do as you described: Yoink *everything* in Monolog, Monolog's dependencies, and their dependencies, etc. into a container-ish thing that gets accessed in a different way than normal.  That doesn't force Monolog to change; it just means that the plugin/module/library using Monolog has to do the leg-work to set up that package in some way before getting to runtime.  It can't just say "grab these 15 files but not these 10 and pull them into a container," since it doesn't know which of those 15 files depend on those 10 files, or vice versa, or what other 20 files one of those 15 depends on that's in a totally different package.

That's like trying to containerize pdo.so and xml.so, but not PHP-FPM or pdo_mysql.so.  Technically Docker will let you, there's just no way it can lead to a working system.

So if it would require globbing together a long chain of dependencies into a thing that you can reliably side-load at once, and expect that set of packages/versions to work together, then something that builds on Phar seems like the natural way to do that.  Essentially using Phar files as the "container image."

You're right, that may not be how Phar works today.  But building that behavior on top of Phar seems vastly easier, more stable, and more likely to lead to something that vaguely resembles a working system than allowing arbitrary code to arbitrarily containerize arbitrary files at runtime and expecting it to go well.

--Larry Garfield