Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127520
Precedence: bulk
MIME-Version: 1.0
References: <CADK1yXKg1xpneLs3vJ=nUAAGaVuBhqkEMgbBVaYfcBfQL2vkDg@mail.gmail.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>
 <354cb888-97c4-4f8c-a0da-359d1e63c0f9@rwec.co.uk> <CAEUnE0dffEmFHV872btX5x_mbwmRmY1GCw+OPPrtr6sLD+u_zg@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>
In-Reply-To: <160E9B1D-9AF6-479B-A628-A73C618D7C1B@garsi.de>
Date: Sun, 1 Jun 2025 01:26:24 -0400
Message-ID: <CAEUnE0eYuvQWMJ6cffhyT-=A-Tj4WiknfALE0jfV=OHoqKMSsw@mail.gmail.com>
Subject: Re: [PHP-DEV] Module or Class Visibility, Season 2
To: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000019c17206367be4b9"
From: tendoaki@gmail.com (Michael Morris)

--00000000000019c17206367be4b9
Content-Type: text/plain; charset="UTF-8"

Ok, the conversation is getting sidetracked, but I think some progress is
being made.

I started this latest iteration last year with a thread about introducing
something similar to the ES module system of JavaScript to PHP. What
attracts me to this particular model is that it should already be familiar
to the vast majority of PHP users. Prior to ES modules browsers had no
natural module import mechanic.  Prior to ES modules all symbols were
attached to the window. You can see this if you serve open this index.html
from a server (Note that opening the file locally will result in the js
being blocked by modern browser security. )

```html
<!DOCTYPE html>
<html>
  <head>
    <script>
      var a = 1234
    </script>
  </head>
  <body>
    <script>
      console.log(a)
      console.log(window.a)
    </script>
  </body>
</html>
```
The above spits 1234 into the console twice.  Second example - let's put a
module in.

```html
<!DOCTYPE html>
<html>
  <head>
    <script>
      var a = 1234
    </script>
    <script type="module">
      const a = 5678
      var b = 9123
    </script>
  </head>
  <body>
    <script>
      console.log(a)
      console.log(window.a)
      console.log(b)
    </script>
  </body>
</html>
```
This outputs 1234 twice and an error is raised about b being undefined.

I bring the above up to demonstrate that is the desired behavior of what I
originally called a PHP module and have been bullied over and taken to task
about not understanding the meaning of "module". Rowain seems to be more
comfortable characterizing this as containers. If everyone is happy with
that term I really don't care - I just want a way to isolate a code block
so that whatever happens in there stays in there unless I explicitly export
it out, and the only way I see things in that scope is if I bring them in.

The other thing that was done with ES is that the syntax for the modules
was tightened. JavaScripters cannot dictate what browser a user chooses, so
the bad decisions of the early days of JS never really went away until ES
came along which enforced their strict mode by default.  PHP has no such
strict mode - it has a strict types mode but that isn't the same thing.
There are multiple behaviors in PHP that can't go away because of backwards
compatibility problems, and one of those might indeed be how namespaces are
handled. In PHP a namespace is just a compile shortcut for resolving symbol
names. The namespace is prefixed to the start of every symbol within it.
Unlike Java or C#, PHP has no concept of namespace visibility. At the end
of the day it's a shortcut and its implementation happens entirely at
compile time.

Previously in the discussion Alwin Garside made a long but insightful post
on namespaces and their workings that I've been thinking on and trying to
digest for the last several days. What I've arrived at is the
discussions about composer and autoloaders are indeed a red herring to the
discussion. At the end of the day, PHP's include statements are a means to
separate the php process into multiple files. In his email he explored some
of the rewriting that could be done, and myself and Rowain have also
explored this in the form of namespace pathing and aliasing.

We've gotten away from the original focus of containing this code and how
that would work. So once again this moron is going to take a stab at it.

Container modules are created with require_module('file/path'). All code
that executes as a result of this call is isolated to its container. That
includes the results of any require or include calls made by the module
file itself or any file it requires.

Since the module file is cordoned off to its own container from the rest of
the application whatever namespaces it uses are irrelevant to outside code.
Any symbols created in the module will not be established in the script
that made the require_module() call. Since it is coming into being with a
new require mechanism it could be subjected to more efficient parsing rules
if that is desired, but that's a massive can of worms for later discussion.
One of those will be necessary - it will need to return something to the
php code that called it.  The simplest way to go about this is to just
require that it have a return. So...

$myModule = require_module('file/path');

or perhaps

const myModule = require_module('file/path');

The module probably should return a static class or class instance, but it
could return a closure.  In JavaScript the dynamic import() statement
returns a module object that is most similar to PHP's static classes, with
each export being a member or method of the module object.

Circling back to a question I know will be asked - what about autoloaders?
To which I answer, what about them? If the module wants to use an
autoloader it has to require one just as the initial php file that required
it had to have done at some point.  The container module is for all intents
and purposes its own php process that returns some interface to allow it to
talk to the process that spawned it.

Will this work? I think yes. Will it be efficient? Hell no. Can it be
optimized somehow? I don't know.

--00000000000019c17206367be4b9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Ok, the conversation is getting sidetracked, but I think s=
ome progress is being made.<div><br></div><div>I started this latest iterat=
ion last year with a thread about introducing something similar to the ES m=
odule system of JavaScript to PHP. What attracts me to this particular mode=
l is that it should already be familiar to the vast majority of PHP users. =
Prior to ES modules browsers had no natural module import mechanic.=C2=A0 P=
rior to ES modules all symbols were attached to the window. You can see thi=
s if you serve open this index.html from a server (Note that opening the fi=
le locally will result in the js being blocked by modern browser security. =
)</div><div><br></div><div>```html</div><div>&lt;!DOCTYPE html&gt;<br>&lt;h=
tml&gt;<br>=C2=A0 &lt;head&gt;<br>=C2=A0 =C2=A0 &lt;script&gt;<br>=C2=A0 =
=C2=A0 =C2=A0 var a =3D 1234<br>=C2=A0 =C2=A0 &lt;/script&gt;<br>=C2=A0 &lt=
;/head&gt;<br>=C2=A0 &lt;body&gt;<br>=C2=A0 =C2=A0 &lt;script&gt;<br>=C2=A0=
 =C2=A0 =C2=A0 console.log(a)<br>=C2=A0 =C2=A0 =C2=A0 console.log(window.a)=
<br>=C2=A0 =C2=A0 &lt;/script&gt;<br>=C2=A0 &lt;/body&gt;<br>&lt;/html&gt;<=
/div><div>```</div><div>The above spits 1234 into the console twice.=C2=A0 =
Second example - let&#39;s put a module in.</div><div><br></div><div>```htm=
l</div><div>&lt;!DOCTYPE html&gt;<br>&lt;html&gt;<br>=C2=A0 &lt;head&gt;<br=
>=C2=A0 =C2=A0 &lt;script&gt;<br>=C2=A0 =C2=A0 =C2=A0 var a =3D 1234<br>=C2=
=A0 =C2=A0 &lt;/script&gt;<br>=C2=A0 =C2=A0 &lt;script type=3D&quot;module&=
quot;&gt;<br>=C2=A0 =C2=A0 =C2=A0 const a =3D 5678<br>=C2=A0 =C2=A0 =C2=A0 =
var b =3D 9123<br>=C2=A0 =C2=A0 &lt;/script&gt;<br>=C2=A0 &lt;/head&gt;<br>=
=C2=A0 &lt;body&gt;<br>=C2=A0 =C2=A0 &lt;script&gt;<br>=C2=A0 =C2=A0 =C2=A0=
 console.log(a)<br>=C2=A0 =C2=A0 =C2=A0 console.log(window.a)<br>=C2=A0 =C2=
=A0 =C2=A0 console.log(b)<br>=C2=A0 =C2=A0 &lt;/script&gt;<br>=C2=A0 &lt;/b=
ody&gt;<br>&lt;/html&gt;</div><div>```</div><div>This outputs 1234 twice an=
d an error is raised about b being undefined.</div><div><br></div><div>I br=
ing the above up to demonstrate that is the desired behavior of what I orig=
inally called a PHP module and have been bullied over and taken to task abo=
ut not understanding the meaning of &quot;module&quot;. Rowain seems to be =
more comfortable characterizing this as containers. If everyone is happy wi=
th that term I really don&#39;t care - I just want a way to isolate a code =
block so that whatever happens in there stays in there unless I explicitly =
export it out, and the only way I see things in that scope is if I bring th=
em in.</div><div><br></div><div>The other thing that was done with ES is th=
at the syntax for the modules was tightened. JavaScripters cannot dictate w=
hat browser a user chooses, so the bad decisions of the early days of JS ne=
ver really went away until ES came along which enforced their strict mode b=
y default.=C2=A0 PHP has no such strict mode - it has a strict types mode b=
ut that isn&#39;t the same thing.=C2=A0 There are multiple behaviors in PHP=
 that can&#39;t go away because of backwards compatibility problems, and on=
e of those might indeed be how namespaces are handled. In PHP a namespace i=
s just a compile shortcut for resolving symbol names. The namespace is pref=
ixed to the start of every symbol within it. Unlike Java or C#, PHP has no =
concept of namespace visibility. At the end of the day it&#39;s a shortcut =
and its implementation happens entirely at compile time.</div><div><br></di=
v><div>Previously in the discussion Alwin Garside made a long but insightfu=
l post on namespaces and their workings that I&#39;ve been thinking on and =
trying to digest for the last several days. What I&#39;ve arrived at is the=
 discussions=C2=A0about composer and autoloaders are indeed a red herring t=
o the discussion. At the end of the day, PHP&#39;s include statements are a=
 means to separate the php process into multiple files. In his email he exp=
lored some of the rewriting that could be done, and myself and Rowain have =
also explored this in the form of namespace pathing and aliasing.</div><div=
><br></div><div>We&#39;ve gotten away from the original focus of containing=
 this code and how that would work. So once again this moron is going to ta=
ke a stab at it.</div><div><br></div><div>Container modules are created wit=
h require_module(&#39;file/path&#39;). All code that executes as a result o=
f this call is isolated to its container. That includes the results of any =
require or include calls made by the module file itself or any file it requ=
ires.</div><div><br></div><div>Since the module file is cordoned off to its=
 own container from the rest of the application whatever namespaces it uses=
 are irrelevant to outside code. Any symbols created in the module will not=
 be established in the script that made the require_module() call. Since it=
 is coming into being with a new require mechanism it could be subjected to=
 more efficient parsing rules if that is desired,=C2=A0but that&#39;s a mas=
sive=C2=A0can of worms for later discussion. One of those will be necessary=
 - it will need to return something to the php code that called it.=C2=A0 T=
he simplest way to go about this is to just require that it have a return. =
So...</div><div><br></div><div>$myModule =3D require_module(&#39;file/path&=
#39;);</div><div><br></div><div>or perhaps</div><div><br></div><div>const m=
yModule =3D require_module(&#39;file/path&#39;);</div><div><br></div><div>T=
he module probably should return a static class or class instance, but it c=
ould return a closure.=C2=A0 In JavaScript the dynamic import() statement r=
eturns a module object that is most similar to PHP&#39;s=C2=A0static classe=
s, with each export being a member or method of the module object.</div><di=
v><br></div><div>Circling back to a question I know will be asked - what ab=
out autoloaders?=C2=A0 To which I answer, what about them? If the module wa=
nts to use an autoloader it has to require one just as the initial php file=
 that required it had to have done at some point.=C2=A0 The container modul=
e is for all intents and purposes its own php process that=C2=A0returns som=
e interface to allow it to talk to the process that=C2=A0spawned it.=C2=A0<=
/div><div><br></div><div>Will this work? I think yes. Will it be efficient?=
 Hell no. Can it be optimized somehow? I don&#39;t know.</div><div><br></di=
v></div>

--00000000000019c17206367be4b9--