Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127429
Feedback-ID: id5114917:Fastmail
Content-Type: multipart/alternative;
 boundary="------------BjAe0ZgzJQiMmSddGCoEd7aH"
Message-ID: <354cb888-97c4-4f8c-a0da-359d1e63c0f9@rwec.co.uk>
Date: Thu, 22 May 2025 21:29:18 +0100
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] Module or Class Visibility, Season 2
To: internals@lists.php.net
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>
 <9f6a0d6e-27c3-4f77-aed6-e55147442b6f@app.fastmail.com>
 <B46C391D-2248-4E54-BFBE-2195FFB6A2A5@rwec.co.uk>
 <ca5c49c9-948a-48f0-8b94-86fea583fbc4@app.fastmail.com>
 <673fd2db-b07f-439b-a4f2-e9519108d159@app.fastmail.com>
 <CAEUnE0dxRwjhKC64XHWkF3bNRLgjkgSJ9oMajRPfwLoDWy3x-g@mail.gmail.com>
 <78641D8B-AF1D-4912-920A-D75A37C32F05@rwec.co.uk>
 <CAEUnE0dVyQ9NQonEBU6wkKM+WsyLXt68jAGYjsz270w_Fa8=Fw@mail.gmail.com>
 <CF275E74-F6AE-4357-8586-2FF17DC84FB5@rwec.co.uk>
 <CAEUnE0eR-0c=pDxgFrB4n60rGescZDVzOgb4uJbYK1aLvQE8=A@mail.gmail.com>
Content-Language: en-GB
In-Reply-To: <CAEUnE0eR-0c=pDxgFrB4n60rGescZDVzOgb4uJbYK1aLvQE8=A@mail.gmail.com>
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")

This is a multi-part message in MIME format.
--------------BjAe0ZgzJQiMmSddGCoEd7aH
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 22/05/2025 12:09, Michael Morris wrote:
>
>
>     I've tried several times to explain why I think Linux containers
>     are a good analogy; I'm not sure if you didn't understand, or just
>     didn't agree, so I don't know what else I can say.
>
>
> I have no disagreement with that, but it's an implementation detail. 
> I'm not there yet - I'm just trying to describe what I think is needed 
> from outside the engine.


I think this is where we're not seeing eye to eye, and why we're getting 
frustrated with each other, because I see it as far more fundamental 
than details you have already gone into, like how autoloading will work.

Perhaps a more realistic example will help, and also avoid the confusion 
over "A, B, and D" from earler.

Imagine a WordPress plugin, AlicesCalendar, which uses the Composer 
packages monolog/monolog and google/apiclient. The google/apiclient 
package also requires monolog/monolog.

Another WordPress plugin, BobsDocs, also uses both monolog/monolog and 
google/apiclient, but using different versions.


Inside those different places, there are lines of code like this:

$logger = new \Monolog\Logger('alices-calendar'); // in AlicesCalendar
$logger = new \Monolog\Logger('bobs-docs'); // in BobsDocs
$logger = new \Monolog\Logger('google-api-php-client'); // in 
google/apiclient

We need to rewrite those lines so that they all refer to the correct 
version of Monolog\Logger.


If every package/module/whatever rewrites the classes inside every other 
package/module/whatever, we might start with this:

$logger = new \AlicesCalendar\Monolog\Logger('alices-calendar'); // in 
AlicesCalendar
$logger = new \BobsDocs\Monolog\Logger('bobs-docs'); // in BobsDocs
$logger = new \GoogleApiClient\Monolog\Logger('google-api-php-client'); 
// in google/apiclient


That only works if we somehow know that AlicesCalendar and BobsDocs use 
the same google/apiclient; if not, we need four copies:

$logger = new \AlicesCalendar\Monolog\Logger('alices-calendar'); // in 
AlicesCalendar
$logger = new 
\AlicesCalendar\GoogleApiClient\Monolog\Logger('google-api-php-client'); 
// in google/apiclient when called from AlicesCalendar

$logger = new \BobsDocs\Monolog\Logger('bobs-docs'); // in BobsDocs
$logger = new 
\BobsDocs\GoogleApiClient\Monolog\Logger('google-api-php-client'); // in 
google/apiclient when called from BobsDocs

All of these are separate classes, which can't be used interchangeably, 
and the names get longer and longer to isolate dependencies inside 
dependencies.


But we don't actually need the Monolog\Logger used by AlicesCalendar to 
be a different version from the one used by google/api-client. In fact, 
it would be useful if they were the same, so we could pass around the 
objects interchangeably *inside* the plugin code.

So what we want is some way of saying that AlicesCalendar and BobsDocs 
are special; they want to isolate code in a way that normal 
modules/packages/whatever don't. Then we can have 2 copies of 
Monolog\Logger, not 3 or 4:

$logger = new \AlicesCalendar\Monolog\Logger('alices-calendar'); // in 
AlicesCalendar
$logger = new \AlicesCalendar\Monolog\Logger('google-api-php-client'); 
// in google/apiclient when called from AlicesCalendar

$logger = new \BobsDocs\Monolog\Logger('bobs-docs'); // in BobsDocs
$logger = new \BobsDocs\Monolog\Logger('google-api-php-client'); // in 
google/apiclient when called from BobsDocs

In this case, PHP doesn't need to know monolog/monolog even exists. It 
just puts either "AlicesCalendar" or "BobsDocs" on any class name it sees.


Before we can even think about *how* we'd implement the rewriting (or 
shadowing, or whatever) we need some requirements of *what* we want to 
rewrite. By suggesting an image of "containers" or "sandboxes" rather 
than "packages" or "modules", I was trying to define the requirement 
that "AlicesCalendar and BobsDocs are special, in a way that 
monolog/monolog and google/apiclient are not".


-- 
Rowan Tommins
[IMSoP]


--------------BjAe0ZgzJQiMmSddGCoEd7aH
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 22/05/2025 12:09, Michael Morris
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAEUnE0eR-0c=pDxgFrB4n60rGescZDVzOgb4uJbYK1aLvQE8=A@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">
        <div class="gmail_quote gmail_quote_container">
          <blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
            <br>
            I've tried several times to explain why I think Linux
            containers are a good analogy; I'm not sure if you didn't
            understand, or just didn't agree, so I don't know what else
            I can say.<br>
          </blockquote>
          <div><br>
          </div>
          <div>I have no disagreement with that, but it's an
            implementation detail. I'm not there yet - I'm just trying
            to describe what I think is needed from outside the engine.</div>
        </div>
      </div>
    </blockquote>
    <p><br>
    </p>
    <p>I think this is where we're not seeing eye to eye, and why we're
      getting frustrated with each other, because I see it as far more
      fundamental than details you have already gone into, like how
      autoloading will work.</p>
    <p>Perhaps a more realistic example will help, and also avoid the
      confusion over "A, B, and D" from earler.</p>
    <p>Imagine a WordPress plugin, AlicesCalendar, which uses the
      Composer packages monolog/monolog and google/apiclient. The
      google/apiclient package also requires monolog/monolog.</p>
    <p>Another WordPress plugin, BobsDocs, also uses both
      monolog/monolog and google/apiclient, but using different
      versions.</p>
    <p><br>
    </p>
    <p>Inside those different places, there are lines of code like this:</p>
    <p>$logger = new \Monolog\Logger('alices-calendar'); // in
      AlicesCalendar<br>
      $logger = new \Monolog\Logger('bobs-docs'); // in BobsDocs<br>
      $logger = new \Monolog\Logger('google-api-php-client'); // in
      google/apiclient</p>
    <p>We need to rewrite those lines so that they all refer to the
      correct version of Monolog\Logger.</p>
    <p><br>
    </p>
    <p>If every package/module/whatever rewrites the classes inside
      every other package/module/whatever, we might start with this:</p>
    <p>$logger = new \AlicesCalendar\Monolog\Logger('alices-calendar');
      // in AlicesCalendar<br>
      $logger = new \BobsDocs\Monolog\Logger('bobs-docs'); // in
      BobsDocs<br>
      $logger = new
      \GoogleApiClient\Monolog\Logger('google-api-php-client'); // in
      google/apiclient</p>
    <p><br>
    </p>
    <p>That only works if we somehow know that AlicesCalendar and
      BobsDocs use the same google/apiclient; if not, we need four
      copies:</p>
    <p>$logger = new \AlicesCalendar\Monolog\Logger('alices-calendar');
      // in AlicesCalendar<br>
      $logger = new
      \AlicesCalendar\GoogleApiClient\Monolog\Logger('google-api-php-client');
      // in google/apiclient when called from AlicesCalendar</p>
    <p>
      $logger = new \BobsDocs\Monolog\Logger('bobs-docs'); // in
      BobsDocs<br>
      $logger = new
      \BobsDocs\GoogleApiClient\Monolog\Logger('google-api-php-client');
      // in google/apiclient when called from BobsDocs</p>
    <p></p>
    <p>All of these are separate classes, which can't be used
      interchangeably, and the names get longer and longer to isolate
      dependencies inside dependencies.</p>
    <p><br>
    </p>
    <p>But we don't actually need the Monolog\Logger used by
      AlicesCalendar to be a different version from the one used by
      google/api-client. In fact, it would be useful if they were the
      same, so we could pass around the objects interchangeably *inside*
      the plugin code.</p>
    <p>So what we want is some way of saying that AlicesCalendar and
      BobsDocs are special; they want to isolate code in a way that
      normal modules/packages/whatever don't. Then we can have 2 copies
      of Monolog\Logger, not 3 or 4:</p>
    <p>$logger = new \AlicesCalendar\Monolog\Logger('alices-calendar');
      // in AlicesCalendar<br>
      $logger =
      new \AlicesCalendar\Monolog\Logger('google-api-php-client'); // in
      google/apiclient when called from AlicesCalendar</p>
    <p>
      $logger = new \BobsDocs\Monolog\Logger('bobs-docs'); // in
      BobsDocs<br>
      $logger = new \BobsDocs\Monolog\Logger('google-api-php-client');
      // in google/apiclient when called from BobsDocs</p>
    <p>In this case, PHP doesn't need to know monolog/monolog even
      exists. It just puts either "AlicesCalendar" or "BobsDocs" on any
      class name it sees.</p>
    <p><br>
    </p>
    <p>Before we can even think about *how* we'd implement the rewriting
      (or shadowing, or whatever) we need some requirements of *what* we
      want to rewrite. By suggesting an image of "containers" or
      "sandboxes" rather than "packages" or "modules", I was trying to
      define the requirement that "AlicesCalendar and BobsDocs are
      special, in a way that monolog/monolog and google/apiclient are
      not".</p>
    <p><br>
    </p>
    <p>-- <br>
      Rowan Tommins<br>
      [IMSoP]</p>
    <p><br>
    </p>
  </body>
</html>

--------------BjAe0ZgzJQiMmSddGCoEd7aH--