Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123911
Precedence: bulk
MIME-Version: 1.0
Date: Wed, 26 Jun 2024 22:15:47 -0400
Message-ID: <CAEUnE0fGZ3jFiBG=GyvnhBzH5a0iO4=n75PM=3+6zLAMrumEvA@mail.gmail.com>
Subject: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6
 from JavaScript
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000002dd7ab061bd5b62f"
From: tendoaki@gmail.com (Michael Morris)

--0000000000002dd7ab061bd5b62f
Content-Type: text/plain; charset="UTF-8"

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 optimizations
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 the
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.

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 vantage
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.

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 initial
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 the
interpreter, such as the index.php of Drupal. Files that are included with
include, include_once, require, or require_once will be imported as they
always have.  Files that are included with import are PHP User Modules.

User Module Files
PHP User Modules have the following properties (Proposed, and very much
subject to change):
* They are code files.  They have no <?php or ?> tags, and the inclusion of
those tags is a parse exception. I know this will be problematic for PHP
storm and other IDE's, but it's not an insurmountable problem.
* If the removal of HEREDOC and NOWDOC syntax would simplify the parser,
then these too would be removed from User Modules.
* They have no starting symbol table.  Each class, function or constant to
be used must be imported with the import statement. Symbols declared in a
user module do not affect the symbol tables of the rest of the runtime.
* They have their own variable scope. They do not by default see globals or
superglobals. Variables declared in a module remain in that module.
Superglobals can be imported (Ideally this is an opportunity to provide new
more secure ways of accessing this data as several userland libraries have
done).
* They have no support for braceless syntax (which is only really useful
when PHP is used as a template engine).
* User Modules run in strict mode.
* Exceptions only. trigger_error will cause a parse exception.
* The @ error suppression operator is not supported.
* Top level return to stop parsing of the file early (as in include and
require) is not supported.
* If at all possible, . as a connotation operator will not be supported and
instead that operator will be used for scope resolution instead of the
three scope resolution operators currently in use for legacy reasons (::,
-> and \ )
* Other language features whose use is considered bad practice are also up
for chopping.


Import Statement
PHP User modules are loaded by importing them, not by using include or
require. It's syntax is similar to JavaScript's, but not exact - for one
unlike JavaScript there need not be a from clause.

User Modules can't use code that hasn't been imported to their symbol
table.  So if you want to use str_pos you need to import it

```
import str_pos
```

An import of a symbol will search for that symbol using the existing
resolution rules, and if the symbol is not found the autoloaders are
invoked. Once all have ran the import is retried and if the symbol now
exists globally it can be imported.  This somewhat weird approach ensures
that user modules aren't cut off from the existing ecosystem.

Why not just require, or bother with importing existing symbols? My idea
here is clarity. It should be easier on the IDE's and probably on the
parser if these are called out. Also, explicitly importing functions makes
it easier to get to fixed versions, which is a repeated stumbling block of
many an RFC. I hereby invoke the ghost of PHP 6 and unicode.  That failed
because it was too much to do in one pass.  Import allows language
improvements to arrive piecemeal, and allows some of them to be userland.
More on that in a bit.

As with Javascript, aliasing is allowed.

```
import str_pos as strPos
```

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 the
first file loaded), then recursively look for a php_modules directory until
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.

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 modules 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"

All exports of a file can be brought in with a wildcard

```
import * from "file.php"
```

Should a wildcard be allowed without the from clause?  That is `import *`.
To me this would mean "bring in the master symbol table"  I'm not sure if
that's a good idea as it feels like a bad practice.

Also note, if foo.php doesn't export foo, the import will fail with an
exception. Which brings us to...


Export statement

PHP User Modules export code out using an export statement. If this didn't
happen there wouldn't be much point to them. Constants, classes and
functions can be exported.  Unlike JavaScript, there is no default export
as there isn't an export object in the same sense as JavaScript.

```
export class Animal {}
export const pi = 3.141527
export function foo {}
```

As in Javascript exports can be sourced with a from clause. This is most
frequently seen in packages.

```
export MyClass from "./MyClass.php"
export * from "./methods.php"
```
The wildcard allowing for all exports of another file to be exported at a
common point, simplifying package interfaces.

Aliases are also possible. For example, say you want to use multibyte
string functions by default.  You can do this in one file now

```
export mb_str_pad as strPad;
export mb_str_split as strSplit;
```
And so on, then import

```
import * from "myMbAliases.php"
```

If you got this far, thank you. This overall idea to take one of the better
things to happen to JavaScript in the last decade and incorporate it into
PHP has been bothering me for awhile so I figured I'd share.  I don't know
how much merit there is to this though.

Note there's a lot more to JavaScript's implementation of import and export
that I only touched on here, but this letter has gone on long enough for a
surface level idea pitch.

Mod Note: It's been so long since I've sent any mail to the list that I'm
getting mail from an address I no longer have access to -
dmgx.michael@gmail.com.  Is it possible to unsubscribe that email?

--0000000000002dd7ab061bd5b62f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hello all. This is a ramble of an idea that&#39;s managed =
to 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 sha=
re 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 h=
ave been passed over because of background compatibility. And then there is=
 the issue that PHP has multiple design flaws that seem impossible to get r=
id of. Finally, I sense from conversations I&#39;ve read that there are a l=
ot of engine parser optimizations that haven&#39;t been tried because of th=
e background compatibility problems present.</div><div><br></div><div>JavaS=
cript was in this position as well 10 years ago when JavaScript modules wer=
e introduced with the ES6 syntax. Only recently have these modules finally =
begun to become first class members of node.js.=C2=A0 The existing CommonJS=
 require mechanism remains and will remain in Node for the foreseeable futu=
re, but the ES6 syntax allows an opportunity to sidestep the issue. The mos=
t significant=C2=A0of these is JavaScript modules run in strict mode, which=
 actually removes features that are problematic for the engine or make it d=
ifficult to create optimized code.</div><div><br></div><div>Something simil=
ar could be done in PHP, and that&#39;s what the remainder of this letter i=
s 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 th=
e Zend engine. In the text to follow I&#39;m going to make wrong calls on s=
ome things - maybe multiple things. I&#39;m not married to anything here.=
=C2=A0 Further, even if I were a master of the engine and knew where to sta=
rt, the scope of this is too large for any one person to undertake.</div><d=
iv><br></div><div>So all that said, I&#39;ll begin.</div><div><br></div><di=
v>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.</div=
><div><br></div><div>The only background compatibility break is the introdu=
ction of three keywords: &quot;import&quot;, &quot;export&quot; and &quot;f=
rom&quot;</div><div><br></div><div>The PHP interpreter does not load PHP fi=
les as modules unless it is directed to do so in an ini file or an .htacces=
s file using the default_filetype directive.=C2=A0 If this directive is mis=
sing its value will be &quot;default&quot; - the value &quot;module&quot; w=
ill be used to trigger loading the initial PHP file as a module, and furthe=
r 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 loade=
d by the interpreter, such as the index.php of Drupal. Files that are inclu=
ded with include, include_once, require, or require_once will be imported a=
s they always have.=C2=A0 Files that are included with import are PHP User =
Modules.</div><div><br></div><div>User Module Files</div><div>PHP User Modu=
les have the following properties (Proposed, and very much subject to chang=
e):</div><div>* They are code files.=C2=A0 They have no &lt;?php or ?&gt; t=
ags, and the inclusion of those tags is a=C2=A0parse exception. I know this=
 will be problematic for PHP storm and other IDE&#39;s, but it&#39;s not an=
 insurmountable problem.</div><div>* If the removal of HEREDOC and NOWDOC s=
yntax would simplify the parser, then these too=C2=A0would be removed from =
User Modules.</div><div>* They have no starting symbol table.=C2=A0 Each cl=
ass, function or constant to be used must be imported with the import state=
ment. Symbols declared in a user module do not affect the symbol tables of =
the rest of the runtime.</div><div>* They have their own variable scope. Th=
ey do not by default see globals or superglobals. Variables declared in a=
=C2=A0module remain in that module. Superglobals can be imported (Ideally t=
his is an opportunity to provide new more secure ways of accessing this dat=
a as several userland libraries have done).</div><div>* They have no suppor=
t for braceless syntax (which is only really useful when PHP is used as a t=
emplate engine).</div><div>* User Modules run in strict mode.</div><div>* E=
xceptions only. trigger_error will cause a parse exception.</div><div>* The=
=C2=A0@ error suppression=C2=A0operator is not supported.</div><div>* Top l=
evel return to stop parsing of the file early (as in include and require) i=
s not supported.</div><div>* If at all possible, . as a connotation operato=
r will not be supported and instead that operator will be used for scope re=
solution instead of the three scope resolution operators currently in use f=
or legacy reasons (::, -&gt; and \ )</div><div>* Other language features wh=
ose use is considered bad practice are also up for chopping.</div><div><br>=
</div><div><br></div><div>Import Statement</div><div>PHP User modules are l=
oaded by importing them, not by using include or require. It&#39;s syntax i=
s similar to JavaScript&#39;s, but not exact - for one unlike JavaScript th=
ere need not be a from clause.</div><div><br></div><div>User Modules can=
9;t use code that hasn&#39;t been imported to their symbol table.=C2=A0 So =
if you want to use str_pos you need to import it</div><div><br></div><div>`=
``</div><div>import str_pos</div><div>```</div><div><br></div><div>An impor=
t of a symbol will search for that symbol using the existing resolution rul=
es, and if the symbol is not found the autoloaders are invoked. Once all ha=
ve ran the import is retried and if the symbol now exists globally it can b=
e imported.=C2=A0 This somewhat weird approach ensures that user modules ar=
en&#39;t cut off from the existing ecosystem.</div><div><br></div><div>Why =
not just require, or bother with importing existing symbols? My idea here i=
s clarity. It should be easier on the IDE&#39;s and probably on the parser =
if these are called out. Also, explicitly importing functions makes it easi=
er to get to fixed versions, which is a repeated stumbling block of many an=
 RFC. I hereby invoke the ghost of PHP 6 and unicode.=C2=A0 That failed bec=
ause it was too much to do in one pass.=C2=A0 Import allows language improv=
ements to arrive piecemeal, and allows some of them to be userland. More on=
 that in a bit.</div><div><br></div><div>As with Javascript, aliasing is al=
lowed.</div><div><br></div><div>```</div><div>import str_pos as strPos</div=
><div>```</div><div><br></div><div>The fun really starts when the from clau=
se shows up.</div><div><br></div><div>```</div><div>import foo from &quot;f=
oo.php&quot;</div><div>```</div><div><br></div><div>The search order of imp=
ort is as follows:</div><div>1. Is the file in the same directory as the im=
porting 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 lo=
ok for a php_modules directory until at the cwd until the file is found (th=
is is identical to the seek process of node with it&#39;s analogous node_mo=
dules directory</div><div>4. As a final try, consider the PHP include_paths=
.</div><div><br></div><div>This will of course require a package manager si=
milar to composer to become part of core. However, composer will not be ecl=
ipsed as the import package manager (phppm?) is only concerned with user mo=
dules. These modules must explicitly export any symbols being fetched from =
them, whereas composer will continue to load files using require.</div><div=
><br></div><div>Imports can also be done against 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 parser will look for &quot;mypa=
ckage/index.php&quot;</div><div><br></div><div>All exports of a file can be=
 brought in with a wildcard</div><div><br></div><div>```</div><div>import *=
 from &quot;file.php&quot;</div><div>```</div><div><br></div><div>Should a =
wildcard be allowed without the from clause?=C2=A0 That is `import *`. To m=
e this would mean &quot;bring in the master symbol table&quot;=C2=A0 I&#39;=
m not sure if that&#39;s a good idea as it feels like a bad practice.</div>=
<div><br></div><div>Also note, if foo.php doesn&#39;t export foo, the impor=
t will fail with an exception. Which brings us to...</div><div><br></div><d=
iv><br></div><div>Export statement</div><div><br></div><div>PHP User Module=
s export code out using an export statement. If this didn&#39;t happen ther=
e wouldn&#39;t be much point to them. Constants, classes and functions can =
be exported.=C2=A0 Unlike JavaScript, there is no default export as there i=
sn&#39;t an export object in the same sense as JavaScript.</div><div><br></=
div><div>```</div><div>export class Animal {}</div><div>export const pi =3D=
 3.141527</div><div>export function foo {}</div><div>```</div><div><br></di=
v><div>As in Javascript exports can be sourced with a from clause. This is =
most frequently seen in packages.=C2=A0=C2=A0<br></div><div><br></div><div>=
```</div><div>export MyClass from &quot;./MyClass.php&quot;</div><div>expor=
t * from &quot;./methods.php&quot;</div><div>```</div><div>The wildcard all=
owing for all exports of another file to be exported at a common point, sim=
plifying package interfaces.</div><div><br></div><div>Aliases are also poss=
ible. For example, say you want to use multibyte string functions by defaul=
t.=C2=A0 You can do this in one file now</div><div><br></div><div>```</div>=
<div>export mb_str_pad as strPad;</div><div>export mb_str_split as strSplit=
;</div><div>```</div><div>And so on, then import</div><div><br></div><div>`=
``</div><div>import * from &quot;myMbAliases.php&quot;</div><div>```</div><=
div><br></div><div>If you got this far, thank you. This overall idea to tak=
e one of the better things to happen to JavaScript in the last decade and i=
ncorporate it into PHP has been bothering me for awhile so I figured I&#39;=
d share.=C2=A0 I don&#39;t know how much merit there is to this though.</di=
v><div><br></div><div>Note there&#39;s a lot more to JavaScript&#39;s imple=
mentation of import and export that I only touched on here, but this letter=
 has gone on long enough for a surface level idea pitch.=C2=A0</div><div><b=
r></div><div>Mod Note: It&#39;s been so long since I&#39;ve sent any mail t=
o the list that I&#39;m getting mail from an address I no longer have acces=
s to - <a href=3D"mailto:dmgx.michael@gmail.com">dmgx.michael@gmail.com</a>=
.=C2=A0 Is it possible to unsubscribe that email?</div></div>

--0000000000002dd7ab061bd5b62f--