Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127540
Feedback-ID: id5114917:Fastmail
Content-Type: multipart/alternative;
 boundary="------------fMGZ2pr9uoiJjpVmOsRxuD9U"
Message-ID: <57d08124-fb6a-4e0b-8d42-bdb645571b13@rwec.co.uk>
Date: Mon, 2 Jun 2025 21:28:30 +0100
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] Module or Class Visibility, Season 2
Content-Language: en-GB
To: internals@lists.php.net
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>
In-Reply-To: <5eb5b1b4-7cb2-4a2b-afdd-ad3e83ae856d@app.fastmail.com>
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")

This is a multi-part message in MIME format.
--------------fMGZ2pr9uoiJjpVmOsRxuD9U
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

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:

a) Before or during compilation, every reference is automatically 
prefixed, so that the class is declared as 
"\__SomeMagicPrefix\Monolog\Handler\StreamHandler", and the reference to 
"\Monolog\Utils" is replaced by a reference to 
"\__SomeMagicPrefix\Monolog\Utils". There are existing userland 
implementations that take this approach.

b) While the class is being compiled, PHP swaps out the entire symbol 
table, so that the class is still called 
"\Monolog\Handler\StreamHandler", and the reference to "\Monolog\Utils" 
is to the class of that name in the current symbol table. In a different 
symbol table, both names refer to separately compiled classes.

The "new namespace root" in my last message is either (a) the special 
prefix, or (b) the actual root of the new symbol table. In either case, 
you need to decide which classes to declare under that root; either 
recursively tracking what requires what, or just where on disk the file 
was loaded from.


Even if we're willing to require the authors of Monolog to rewrite their 
library for the convenience of WordPress plugin authors, I don't see how 
we can get away from every class in PHP being fundamentally identified 
by name, and the compiler needing to manage those names somehow.

We can imagine a parallel universe where PHP declarations worked like JS 
or Python:

import * from Monolog\Handler;
...
$Utils = import Monolog\Utils;
...
$StreamHandler = class extends $AbstractProcessingHandler {
...
$this->url = $Utils::canonicalizePath($stream);

But at that point, we're just inventing a new programming language.


> At which point, we're basically talking about "load this Phar file into a custom internalized namespace", which, from my limited knowledge of Phar, seems like the most logical way to do it.  That also sidesteps all the loading and linking shenanigans.


I don't think Phar files would particularly help. As far as I know, 
they're just a file system wrapper; you still have to include/require 
the individual files inside the archive, and they're still compiled in 
exactly the same way.

Whether we want to isolate "any definition you find in the directory 
/var/www/wordpress/wp-plugins/foo/" or "any definition you find in the 
Phar archive phar:///var/www/wordpress/wp-plugins/foo.phar", the tricky 
part is how to do the actual isolating.


-- 
Rowan Tommins
[IMSoP]

--------------fMGZ2pr9uoiJjpVmOsRxuD9U
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">On 02/06/2025 17:57, Larry Garfield
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:5eb5b1b4-7cb2-4a2b-afdd-ad3e83ae856d@app.fastmail.com">
      <pre class="moz-quote-pre" wrap="">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.  </pre>
    </blockquote>
    <p><br>
    </p>
    <p>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".</p>
    <p><br>
    </p>
    <p>Picking completely at random, a file in Monolog has these lines
      in:</p>
    <p>namespace Monolog\Handler;<br>
      ...<br>
      use Monolog\Utils;<br>
      ...<br>
      class StreamHandler extends AbstractProcessingHandler {<br>
      ...<br>
      $this-&gt;url = Utils::canonicalizePath($stream);</p>
    <p><br>
    </p>
    <p>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:</p>
    <p>a) Before or during compilation, every reference is automatically
      prefixed, so that the class is declared as
      "\__SomeMagicPrefix\Monolog\Handler\StreamHandler", and the
      reference to "\Monolog\Utils" is replaced by a reference to
      "\__SomeMagicPrefix\Monolog\Utils". There are existing userland
      implementations that take this approach.</p>
    <p>b) While the class is being compiled, PHP swaps out the entire
      symbol table, so that the class is still called
      "\Monolog\Handler\StreamHandler", and the reference to
      "\Monolog\Utils" is to the class of that name in the current
      symbol table. In a different symbol table, both names refer to
      separately compiled classes.</p>
    <p>The "new namespace root" in my last message is either (a) the
      special prefix, or (b) the actual root of the new symbol table. In
      either case, you need to decide which classes to declare under
      that root; either recursively tracking what requires what, or just
      where on disk the file was loaded from.</p>
    <p><br>
    </p>
    <p>Even if we're willing to require the authors of Monolog to
      rewrite their library for the convenience of WordPress plugin
      authors, I don't see how we can get away from every class in PHP
      being fundamentally identified by name, and the compiler needing
      to manage those names somehow.</p>
    <p>We can imagine a parallel universe where PHP declarations worked
      like JS or Python:</p>
    <p>import * from Monolog\Handler;<br>
      ...<br>
      $Utils = import Monolog\Utils;<br>
      ...<br>
      $StreamHandler = class extends $AbstractProcessingHandler {<br>
      ...<br>
      $this-&gt;url = $Utils::canonicalizePath($stream);</p>
    <p>But at that point, we're just inventing a new programming
      language.</p>
    <p><br>
    </p>
    <p><span style="white-space: pre-wrap">
</span></p>
    <blockquote type="cite"
      cite="mid:5eb5b1b4-7cb2-4a2b-afdd-ad3e83ae856d@app.fastmail.com">
      <pre class="moz-quote-pre" wrap="">At which point, we're basically talking about "load this Phar file into a custom internalized namespace", which, from my limited knowledge of Phar, seems like the most logical way to do it.  That also sidesteps all the loading and linking shenanigans.
</pre>
    </blockquote>
    <p><br>
    </p>
    <p>I don't think Phar files would particularly help. As far as I
      know, they're just a file system wrapper; you still have to
      include/require the individual files inside the archive, and
      they're still compiled in exactly the same way.</p>
    <p>Whether we want to isolate "any definition you find in the
      directory /var/www/wordpress/wp-plugins/foo/" or "any definition
      you find in the Phar archive
      phar:///var/www/wordpress/wp-plugins/foo.phar", the tricky part is
      how to do the actual isolating.</p>
    <p><br>
    </p>
    <pre class="moz-signature" cols="72">-- 
Rowan Tommins
[IMSoP]</pre>
  </body>
</html>

--------------fMGZ2pr9uoiJjpVmOsRxuD9U--