Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127524
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> <CAEUnE0eYuvQWMJ6cffhyT-=A-Tj4WiknfALE0jfV=OHoqKMSsw@mail.gmail.com>
 <6cbfb0ca-5be3-4c00-94ba-4595cfad3738@app.fastmail.com>
In-Reply-To: <6cbfb0ca-5be3-4c00-94ba-4595cfad3738@app.fastmail.com>
Date: Sun, 1 Jun 2025 12:08:46 -0400
Message-ID: <CAEUnE0fEzeNOHhdzJxN2GjZ_L9B9s=SsBWVdJUqMVWv12EQTnA@mail.gmail.com>
Subject: Re: [PHP-DEV] Module or Class Visibility, Season 2
To: internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000686961063684dd0b"
From: tendoaki@gmail.com (Michael Morris)

--000000000000686961063684dd0b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, Jun 1, 2025 at 3:18=E2=80=AFAM Rob Landers <rob@bottled.codes> wrot=
e:

> This could work! I have a couple of critiques, but they aren=E2=80=99t ne=
gative:
>
> I think I like it. It might be worth pointing out that JavaScript "hoists=
"
> the imports to file-level during compilation =E2=80=94 even if you have t=
he import
> statement buried deep in a function call. Or, at least it used to. I
> haven=E2=80=99t kept track of the language that well in the last 10 years=
, so I
> wouldn=E2=80=99t be surprised if it changed; or didn=E2=80=99t. I don=E2=
=80=99t think this is
> something we need to worry about too much here.
>

As I pointed out in detail to Rob off list JavaScript has 2 import
mechanisms that are subtly different from each other. Those interested can
read here:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statement=
s/import
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators=
/import


> It=E2=80=99s also worth pointing out that when PHP compiles a file, every=
 file has
> either an explicit or implicit return.
> https://www.php.net/manual/en/function.include.php#:~:text=3DHandling%20R=
eturns%3A,from%20included%20files
> .
>

True, but it's a rarely used mechanism and a return statement isn't
required - hence an implicit return is possible.


>
> So, in other words, what is it about require_module that is different fro=
m
> `require` or `include`? Personally, I would then change PHP from "compile
> file" mode when parsing the file to "compile module" mode. From a totally
> naive point-of-view, this would cause PHP to:
>
>    1. if we already have a module from that file; return the module
>    instead of compiling it again.
>    2. swap out symbol tables to the module=E2=80=99s symbol table.
>    3. start compiling the given file.
>    4. concatenate all files as included/required.
>    5. compile the resulting huge file.
>    6. switch back to the calling symbol table (which may be another
>    module).
>    7. return the module.
>
> For a v1, I wouldn=E2=80=99t allow autoloading from inside a module =E2=
=80=94 or any
> autoloaded code automatically isn=E2=80=99t considered to be part of the =
module (it
> would be the responsibility of the main program to handle autoloading).
> This is probably something that needs to be solved, but I think it would
> need a whole new approach to autoloading which should be out of scope for
> the module RFC (IMHO).
>
> In other words, you can simply include/require a module to load the entir=
e
> module into your current symbol table; or use require_module to "contain"
> it.
>

Yes, that is certainly possible but comes at an opportunity cost from an
engine design standpoint. This is an exceedingly rare opportunity to go
back and fix mistakes that have dogged the language for sometime that
simply can't be fixed without creating large backwards compatibility
problems. For instance, say for the sake of example that PHP files could be
compiled 10 times faster if the object parser could assume the whole file
was code and there's not going to be any <?php ?> tags or Heredoc or Nowdoc
blocks.  It might be worth it then to have modules not allow such, and if
an author had a block of code that they really wanted this templating
behavior to apply to they still could issue a require. Maybe it's time to
dig up some downvoted RFC's that got killed for these reasons.


>
> As for what should a module return? I like your idea of just returning an
> object or closure.
>

I'm leaning towards something akin to a static class.  If modules have
export keywords (note that if they have their own parser they can also have
keywords without disrupting the existing PHP ecosystem) then compiling one
would be a static class with members and methods matching what was exported=
.


> I just had another thought; sorry about the back-to-back emails. This
> wouldn=E2=80=99t preclude something like composer (or something else) fro=
m being
> used to handle dependencies, it would just mean that the package manager
> might export a "Modules" class + constants =E2=80=94 we could also write =
a composer
> plugin that does just this:
> require_once 'vendor/autoload.php';
> $module =3D require_module Vendor\Module::MyModule;
> where Vendor\Module is a generated and autoloaded class containing consts
> to the path of the exported module.


That leads into some thoughts I have on loading modules in general.
require_module is the simplest expression.  That said, 'use module' might
also be appropriate.

require_once 'vendor/autoload.php';

use module Vendor/Module as MyModule;

Something like that?

JavaScript has a distinction between global scope import, which is almost
analogous to our namespaces and use statement, and dynamic scope import,
which is almost analogous to our require statements.  Don't know if it's
useful to us to draw such a distinction.

--000000000000686961063684dd0b
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 Sun, Jun 1, =
2025 at 3:18=E2=80=AFAM Rob Landers &lt;rob@bottled.codes&gt; wrote:</div><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex"><div><div>This could work!=
 I have a couple of critiques, but they aren=E2=80=99t negative:</div><div>=
<br></div><div>I think I like it. It might be worth pointing out that JavaS=
cript &quot;hoists&quot; the imports to file-level during compilation =E2=
=80=94 even if you have the import statement buried deep in a function call=
. Or, at least it used to. I haven=E2=80=99t kept track of the language tha=
t well in the last 10 years, so I wouldn=E2=80=99t be surprised if it chang=
ed; or didn=E2=80=99t. I don=E2=80=99t think this is something we need to w=
orry about too much here.</div></div></blockquote><div><br></div><div>As I =
pointed out in detail to Rob off list JavaScript has 2 import mechanisms th=
at are subtly different from each other. Those interested can read here:</d=
iv><div><a href=3D"https://developer.mozilla.org/en-US/docs/Web/JavaScript/=
Reference/Statements/import">https://developer.mozilla.org/en-US/docs/Web/J=
avaScript/Reference/Statements/import</a></div><div><a href=3D"https://deve=
loper.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/import">htt=
ps://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/im=
port</a></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex"><div><div><br></div><div>It=E2=80=99s also worth pointing out that when=
 PHP compiles a file, every file has either an explicit or implicit return.=
=C2=A0<a href=3D"https://www.php.net/manual/en/function.include.php#:~:text=
=3DHandling%20Returns%3A,from%20included%20files" target=3D"_blank">https:/=
/www.php.net/manual/en/function.include.php#:~:text=3DHandling%20Returns%3A=
,from%20included%20files</a>.</div></div></blockquote><div><br></div><div>T=
rue, but it&#39;s a rarely used mechanism and a return statement isn&#39;t =
required - hence an implicit return is possible.</div><div>=C2=A0</div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
:1px solid rgb(204,204,204);padding-left:1ex"><div><div><br></div><div>So, =
in other words, what is it about require_module that is different from `req=
uire` or `include`? Personally, I would then change PHP from &quot;compile =
file&quot; mode when parsing the file to &quot;compile module&quot; mode. F=
rom a totally naive point-of-view, this would cause PHP to:<br></div><ol><l=
i>if we already have a module from that file; return the module instead of =
compiling it again.</li><li>swap out symbol tables to the module=E2=80=99s =
symbol table.</li><li>start compiling the given file.</li><li>concatenate a=
ll files as included/required.</li><li>compile the resulting huge file.</li=
><li>switch back to the calling symbol table (which may be another module).=
</li><li>return the module.</li></ol><div>For a v1, I wouldn=E2=80=99t allo=
w autoloading from inside a module =E2=80=94 or any autoloaded code automat=
ically isn=E2=80=99t considered to be part of the module (it would be the r=
esponsibility of the main program to handle autoloading). This is probably =
something that needs to be solved, but I think it would need a whole new ap=
proach to autoloading which should be out of scope for the module RFC (IMHO=
).</div><div><br></div><div>In other words, you can simply include/require =
a module to load the entire module into your current symbol table; or use r=
equire_module to &quot;contain&quot; it.</div></div></blockquote><div><br><=
/div><div>Yes, that is certainly possible but comes at an opportunity cost =
from an engine design standpoint. This is an exceedingly rare opportunity t=
o go back and fix mistakes that have dogged the language for sometime that =
simply can&#39;t be fixed without creating large backwards compatibility pr=
oblems. For instance, say for the sake of example that PHP files could be c=
ompiled 10 times faster if the object parser could assume the whole file wa=
s code and there&#39;s not going to be any &lt;?php ?&gt; tags or Heredoc o=
r Nowdoc blocks.=C2=A0 It might be worth it then to have modules not allow =
such, and if an author had a block of code that they really wanted this tem=
plating behavior to apply to they still could issue a require. Maybe it&#39=
;s time to dig up some downvoted RFC&#39;s that got killed for these reason=
s.=C2=A0</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex"><div><div><br></div><div>As for what should a module return? I like y=
our idea of just returning an object or closure.<br></div></div></blockquot=
e><div><br></div><div>I&#39;m leaning towards something akin to a static cl=
ass.=C2=A0 If modules have export keywords (note that if they have their ow=
n parser they can also have keywords without disrupting the existing PHP ec=
osystem) then compiling one would be a static class with members and method=
s matching what was exported.</div><div><br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20=
4,204);padding-left:1ex"><br>I just had another thought; sorry about the ba=
ck-to-back emails. This wouldn=E2=80=99t preclude something like composer (=
or something else) from being used to handle dependencies, it would just me=
an that the package manager might export a &quot;Modules&quot; class + cons=
tants =E2=80=94 we could also write a composer plugin that does just this:<=
br>require_once &#39;vendor/autoload.php&#39;;<br>$module =3D require_modul=
e Vendor\Module::MyModule;<br>where Vendor\Module is a generated and autolo=
aded class containing consts to the path of the exported module.</blockquot=
e><div><br></div><div>That leads into some thoughts I have on loading modul=
es in general.=C2=A0 require_module is the simplest expression.=C2=A0 That =
said, &#39;use module&#39; might also be appropriate.</div><div><br></div><=
div>require_once &#39;vendor/autoload.php&#39;;</div><div><br></div><div>us=
e module Vendor/Module as MyModule;</div><div><br></div><div>Something like=
 that?</div><div><br></div><div>JavaScript has a distinction between global=
 scope import, which is almost analogous to our namespaces and use statemen=
t, and dynamic scope import, which is almost analogous to our require state=
ments.=C2=A0 Don&#39;t know if it&#39;s useful to us to draw such a distinc=
tion.</div></div></div>

--000000000000686961063684dd0b--