Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123949
Precedence: bulk
MIME-Version: 1.0
References: <CAEUnE0fGZ3jFiBG=GyvnhBzH5a0iO4=n75PM=3+6zLAMrumEvA@mail.gmail.com>
In-Reply-To: <CAEUnE0fGZ3jFiBG=GyvnhBzH5a0iO4=n75PM=3+6zLAMrumEvA@mail.gmail.com>
Date: Thu, 27 Jun 2024 15:10:28 -0300
Message-ID: <CADK1yX+E9mvaM_CHJ8tmEx=O70hf8xasbvngh4wvNM8ce8KKGQ@mail.gmail.com>
Subject: Re: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of
 ES6 from JavaScript
To: Michael Morris <tendoaki@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000e84ee4061be30daf"
From: deleugyn@gmail.com (Deleu)

--000000000000e84ee4061be30daf
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Michael,

On Wed, Jun 26, 2024 at 11:21=E2=80=AFPM Michael Morris <tendoaki@gmail.com=
> wrote:

> Hello all. This is a ramble of an idea that's managed to run around my
> head for a few days now. It isn't fully formed, but I've ran the thought
> experiment as far as I can on my own and want to share it with all of you=
.
>
> I've mostly been a lurker and I've seen a lot of RFC's come and go. Of
> those not accepted many have been passed over because of background
> compatibility. And then there is the issue that PHP has multiple design
> flaws that seem impossible to get rid of. Finally, I sense from
> conversations I've read that there are a lot of engine parser optimizatio=
ns
> that haven't been tried because of the background compatibility problems
> present.
>
> JavaScript was in this position as well 10 years ago when JavaScript
> modules were introduced with the ES6 syntax. Only recently have these
> modules finally begun to become first class members of node.js.  The
> existing CommonJS require mechanism remains and will remain in Node for t=
he
> foreseeable future, but the ES6 syntax allows an opportunity to sidestep
> the issue. The most significant of these is JavaScript modules run in
> strict mode, which actually removes features that are problematic for the
> engine or make it difficult to create optimized code.
>

Working with Typescript a little bit does give a vibe that PHP could borrow
some of the concepts there and be improved greatly and I share this
sentiment.


> Something similar could be done in PHP, and that's what the remainder of
> this letter is about, but before I continue I want to make clear my vanta=
ge
> point: I am but a humble user of the code, I'm no expert on the
> underpinnings of the Zend engine. In the text to follow I'm going to make
> wrong calls on some things - maybe multiple things. I'm not married to
> anything here.  Further, even if I were a master of the engine and knew
> where to start, the scope of this is too large for any one person to
> undertake.
>

Who would build it is an extremely key aspect of making changes to PHP.
Ideas are hard enough to survive the RFC process when there's already an
implementation. Finding a sponsor to work on this would be the first step.


> So all that said, I'll begin.
>
> PHP User Modules are php files that are brought into the runtime through =
a
> new parser that is able to generate faster and more concise runtime code =
by
> removing support for problematic features and imposing a strict mode by
> default. They focus on PHP as a language and not as a template engine.
>
> The only background compatibility break is the introduction of three
> keywords: "import", "export" and "from"
>
> The PHP interpreter does not load PHP files as modules unless it is
> directed to do so in an ini file or an .htaccess file using the
> default_filetype directive.  If this directive is missing its value will =
be
> "default" - the value "module" will be used to trigger loading the initia=
l
> PHP file as a module, and further types could in theory be introduced at =
a
> far later date.
>
> Again, this setting only affects the INITIAL PHP script file loaded by th=
e
> interpreter, such as the index.php of Drupal. Files that are included wit=
h
> include, include_once, require, or require_once will be imported as they
> always have.  Files that are included with import are PHP User Modules.
>

Given that ini settings are frowned upon nowadays, I think having a `<?php
declare(modules=3D1);` for the initial file might make the idea more likely
to pass a vote? Or maybe I'd even try to go one step further and say that
whatever file is being executed by SAPI (the first PHP file) could be
interpreted with a dumb lookahead. If the file has import / export syntax,
treat it like PHP Module, otherwise fallback.


The fun really starts when the from clause shows up.
>
> ```
> import foo from "foo.php"
> ```
>
> The search order of import is as follows:
> 1. Is the file in the same directory as the importing file? Yes, load.
> 2. Is there a php_modules directory? If so, is the file in there?
> 3. If the importing file is within the tree of the cwd (established by th=
e
> first file loaded), then recursively look for a php_modules directory unt=
il
> at the cwd until the file is found (this is identical to the seek process
> of node with it's analogous node_modules directory
> 4. As a final try, consider the PHP include_paths.
>

I'm not familiar enough with Javascript / Typescript ecosystem, but I've
only ever seen / used the ability to import using direct filepath. The fact
there's weird behaviors as result of trying to import a file and suddenly a
file all the way from `include_paths` or `php_modules` seems like a no-go
to me. I'd favor using only simple file path navigation and if the file
doesn't exist, error.

Perhaps if the idea gains merit, Composer could offer something similar to
Vite where we can create an alias to a specific folder and then import
things like `from '@package/path/to/file`.


> This will of course require a package manager similar to composer to
> become part of core. However, composer will not be eclipsed as the import
> package manager (phppm?) is only concerned with user modules. These modul=
es
> must explicitly export any symbols being fetched from them, whereas
> composer will continue to load files using require.
>
> Imports can also be done against directories
>
> ```
> import foo from "mypackage"
> ```
>
> In this case the parser will look for "mypackage/index.php"
>

I'm not fond of this either.

----------------

Overall, I think PHP has already reached the limit of surviving with only
PSR-4 and Composer. Single class files were a great solution to get us out
of the nightmare of `require` and `import` on top of PHP files. But more
than once I have had the desire to declare a couple of interfaces in a
single file, or a handful of Enums, etc. It seems like PHP Modules could
also address the issue with function autoloading and package-level
visibility. I like the idea but I'm a bit skeptical until we have some
buy-in from someone that could actually get this implemented.

--=20
Marco Deleu

--000000000000e84ee4061be30daf
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi Michael,</div><br><div class=3D"gmail_quote"><div =
dir=3D"ltr" class=3D"gmail_attr">On Wed, Jun 26, 2024 at 11:21=E2=80=AFPM M=
ichael Morris &lt;<a href=3D"mailto:tendoaki@gmail.com">tendoaki@gmail.com<=
/a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><=
div dir=3D"ltr">Hello all. This is a ramble of an idea that&#39;s managed t=
o run around my head for a few days now. It isn&#39;t fully formed, but I&#=
39;ve ran the thought experiment as far as I can on my own and want to shar=
e it with all of you.<div><br></div><div>I&#39;ve mostly been a lurker and =
I&#39;ve seen a lot of RFC&#39;s come and go. Of those not accepted many ha=
ve been passed over because of background compatibility. And then there is =
the issue that PHP has multiple design flaws that seem impossible to get ri=
d of. Finally, I sense from conversations I&#39;ve read that there are a lo=
t of engine parser optimizations that haven&#39;t been tried because of the=
 background compatibility problems present.</div><div><br></div><div>JavaSc=
ript was in this position as well 10 years ago when JavaScript modules were=
 introduced with the ES6 syntax. Only recently have these modules finally b=
egun to become first class members of node.js.=C2=A0 The existing CommonJS =
require mechanism remains and will remain in Node for the foreseeable futur=
e, but the ES6 syntax allows an opportunity to sidestep the issue. The most=
 significant=C2=A0of these is JavaScript modules run in strict mode, which =
actually removes features that are problematic for the engine or make it di=
fficult to create optimized code.</div></div></blockquote><div><br></div><d=
iv>Working with Typescript a little bit does give a vibe that PHP could bor=
row some of the concepts there and be improved greatly and I share this sen=
timent.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:=
1ex"><div dir=3D"ltr"><div>Something similar could be done in PHP, and that=
&#39;s what the remainder of this letter is about, but before I continue I =
want to make clear my vantage point: I am but a humble user of the code, I&=
#39;m no expert on the underpinnings of the Zend engine. In the text to fol=
low I&#39;m going to make wrong calls on some things - maybe multiple thing=
s. I&#39;m not married to anything here.=C2=A0 Further, even if I were a ma=
ster of the engine and knew where to start, the scope of this is too large =
for any one person to undertake.</div></div></blockquote><div><br></div><di=
v>Who would build it is an extremely key aspect of making changes to PHP. I=
deas are hard enough to survive the RFC process when there&#39;s already an=
 implementation. Finding a sponsor to work on this would be the first step.=
</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><d=
iv dir=3D"ltr"><div>So all that said, I&#39;ll begin.</div><div><br></div><=
div>PHP User Modules are php files that are brought into the runtime throug=
h a new parser that is able to generate faster and more concise runtime cod=
e by removing support for problematic features and imposing a strict mode b=
y default. They focus on PHP as a language and not as a template engine.</d=
iv><div><br></div><div>The only background compatibility break is the intro=
duction of three keywords: &quot;import&quot;, &quot;export&quot; and &quot=
;from&quot;</div><div><br></div><div>The PHP interpreter does not load PHP =
files as modules unless it is directed to do so in an ini file or an .htacc=
ess file using the default_filetype directive.=C2=A0 If this directive is m=
issing its value will be &quot;default&quot; - the value &quot;module&quot;=
 will be used to trigger loading the initial PHP file as a module, and furt=
her types could in theory be introduced at a far later date.</div><div><br>=
</div><div>Again, this setting only affects the INITIAL PHP script file loa=
ded by the interpreter, such as the index.php of Drupal. Files that are inc=
luded with include, include_once, require, or require_once will be imported=
 as they always have.=C2=A0 Files that are included with import are PHP Use=
r Modules.</div></div></blockquote><div><br></div><div>Given that ini setti=
ngs are frowned upon nowadays, I think having a `&lt;?php declare(modules=
=3D1);` for the initial file might make the idea more likely to pass a vote=
? Or maybe I&#39;d even try to go one step further and say that whatever fi=
le is being executed by SAPI (the first PHP file) could be interpreted with=
 a dumb lookahead. If the file has import / export syntax, treat it like PH=
P Module, otherwise fallback.</div><div>=C2=A0</div><div><br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px=
 solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>The fun rea=
lly starts when the from clause shows up.</div><div><br></div><div>```</div=
><div>import foo from &quot;foo.php&quot;</div><div>```</div><div><br></div=
><div>The search order of import is as follows:</div><div>1. Is the file in=
 the same directory as the importing file? Yes, load.</div><div>2. Is there=
 a php_modules directory? If so, is the file in there?</div><div>3. If the =
importing file is within the tree of the cwd (established by the first file=
 loaded), then recursively look for a php_modules directory until at the cw=
d until the file is found (this is identical to the seek process of node wi=
th it&#39;s analogous node_modules directory</div><div>4. As a final try, c=
onsider the PHP include_paths.</div></div></blockquote><div><br></div><div>=
I&#39;m not familiar enough with Javascript / Typescript ecosystem, but I&#=
39;ve only ever seen / used the ability to import using direct filepath. Th=
e fact there&#39;s weird behaviors as result of trying to import a file and=
 suddenly a file all the way from `include_paths` or `php_modules` seems li=
ke a no-go to me. I&#39;d favor using only simple file path navigation and =
if the file doesn&#39;t exist, error.=C2=A0</div><div><br></div><div>Perhap=
s if the idea gains merit, Composer could offer something similar to Vite w=
here we can create an alias to a specific folder and then import things lik=
e `from &#39;@package/path/to/file`.</div><div>=C2=A0</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid r=
gb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>This will of course=
 require a package manager similar to composer to become part of core. Howe=
ver, composer will not be eclipsed as the import package manager (phppm?) i=
s only concerned with user modules. These modules must explicitly export an=
y symbols being fetched from them, whereas composer will continue to load f=
iles using require.</div><div><br></div><div>Imports can also be done again=
st directories</div><div><br></div><div>```</div><div>import foo from &quot=
;mypackage&quot;</div><div>```</div><div><br></div><div>In this case the pa=
rser will look for &quot;mypackage/index.php&quot;</div></div></blockquote>=
<div><br></div><div>I&#39;m not fond of this either.</div><div><br></div><d=
iv>----------------</div><div><br></div><div>Overall, I think PHP has alrea=
dy reached the limit of surviving with only PSR-4 and Composer. Single clas=
s files were a great solution to get us out of the nightmare of `require` a=
nd `import` on top of PHP files. But more than once I have had the desire t=
o declare a couple of interfaces in a single file, or a handful of Enums, e=
tc. It seems like PHP Modules could also address the issue with function au=
toloading and package-level visibility. I like the idea but I&#39;m a bit s=
keptical until we have some buy-in from someone that could actually get thi=
s implemented.</div></div><div><br></div><span class=3D"gmail_signature_pre=
fix">-- </span><br><div dir=3D"ltr" class=3D"gmail_signature"><div dir=3D"l=
tr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><di=
v dir=3D"ltr"><div dir=3D"ltr">Marco Deleu</div></div></div></div></div></d=
iv></div></div></div>

--000000000000e84ee4061be30daf--