Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123930
Feedback-ID: ifab94697:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-538-g1508afaa2-fm-20240616.001-g1508afaa
Precedence: bulk
MIME-Version: 1.0
Message-ID: <1dfa55cb-5789-4090-aa10-f343fd8c4820@app.fastmail.com>
In-Reply-To: 
 <CAEUnE0fGZ3jFiBG=GyvnhBzH5a0iO4=n75PM=3+6zLAMrumEvA@mail.gmail.com>
References: 
 <CAEUnE0fGZ3jFiBG=GyvnhBzH5a0iO4=n75PM=3+6zLAMrumEvA@mail.gmail.com>
Date: Thu, 27 Jun 2024 09:41:21 +0200
To: internals@lists.php.net
Subject: Re: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from
 JavaScript
Content-Type: multipart/alternative;
 boundary=2ac585f0f3d64c6b9bc59052ba7e44c9
From: rob@bottled.codes ("Rob Landers")

--2ac585f0f3d64c6b9bc59052ba7e44c9
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Thu, Jun 27, 2024, at 04:15, Michael Morris 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 though=
t experiment as far as I can on my own and want to share it with all of =
you.
>=20
> 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 com=
patibility. And then there is the issue that PHP has multiple design fla=
ws that seem impossible to get rid of. Finally, I sense from conversatio=
ns I've read that there are a lot of engine parser optimizations that ha=
ven't been tried because of the background compatibility problems presen=
t.
>=20
> JavaScript was in this position as well 10 years ago when JavaScript m=
odules were introduced with the ES6 syntax. Only recently have these mod=
ules finally begun to become first class members of node.js.  The existi=
ng CommonJS require mechanism remains and will remain in Node for the fo=
reseeable future, but the ES6 syntax allows an opportunity to sidestep t=
he issue. The most significant of these is JavaScript modules run in str=
ict mode, which actually removes features that are problematic for the e=
ngine or make it difficult to create optimized code.
>=20
> 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 v=
antage point: I am but a humble user of the code, I'm no expert on the u=
nderpinnings 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 und=
ertake.
>=20
> So all that said, I'll begin.
>=20
> PHP User Modules are php files that are brought into the runtime throu=
gh 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.

FYI, in non-strict mode, this produces a deprecation warning that can be=
 caught and thrown from:

(fn(int $x) =3D> print($x))(123.456); // deprecation warning

but this will work

(fn(int $x) =3D> print($x))(123.000); // this is fine

Both of those are errors in strict types, so you might be tempted to do

fn(int $x) =3D> print($x))((int)$some_var);

but $some_var might not actually be an integer-like (such as null or a s=
tring that becomes zero).

Some of us prefer the more strict, non-strict mode as the built-in stric=
t mode is actually ... uhh, problematic, to say the least, in some busin=
ess cases. So forcing strict mode is probably a non-starter.

>=20
> The only background compatibility break is the introduction of three k=
eywords: "import", "export" and "from"
>=20
> The PHP interpreter does not load PHP files as modules unless it is di=
rected to do so in an ini file or an .htaccess file using the default_fi=
letype directive.  If this directive is missing its value will be "defau=
lt" - 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.
>=20
> Again, this setting only affects the INITIAL PHP script file loaded by=
 the interpreter, such as the index.php of Drupal. Files that are includ=
ed 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.

One of the advantages of the current autoloading file-loading system is =
that files are not included until the are used. This allows you to run M=
ASSIVE projects that realistically only need to load dozens of files. Fo=
r example, I know of some code-bases that have literally millions of PHP=
 files collected over the last 15 years and hundreds of developers worki=
ng on them every day.

>=20
> User Module Files
> PHP User Modules have the following properties (Proposed, and very muc=
h subject to change):
> * They are code files.  They have no <?php or ?> tags, and the inclusi=
on of those tags is a parse exception. I know this will be problematic f=
or PHP storm and other IDE's, but it's not an insurmountable problem.

So, will ?> work? I have turned on output buffering and then just wrote =
out what I needed --- ie, a template, then get the output.=20

> * If the removal of HEREDOC and NOWDOC syntax would simplify the parse=
r, then these too would be removed from User Modules.

Are we sure we want *multiple* PHP parsers to maintain?

=E2=80=94 Rob
--2ac585f0f3d64c6b9bc59052ba7e44c9
Content-Type: text/html;charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title><style type=3D"text/css">p.Mso=
Normal,p.MsoNoSpacing{margin:0}</style></head><body><div>On Thu, Jun 27,=
 2024, at 04:15, Michael Morris wrote:<br></div><blockquote type=3D"cite=
" id=3D"qt" style=3D""><div dir=3D"ltr"><div>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.<br></div><div><br></div>=
<div>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 conversa=
tions I've read that there are a lot of engine parser optimizations that=
 haven't been tried because of the background compatibility problems pre=
sent.<br></div><div><br></div><div>JavaScript was in this position as we=
ll 10 years ago when JavaScript modules were introduced with the ES6 syn=
tax. Only recently have these modules finally begun to become first clas=
s members of node.js.&nbsp; The existing CommonJS require mechanism rema=
ins and will remain in Node for the foreseeable future, but the ES6 synt=
ax allows an opportunity to sidestep the issue. The most significant&nbs=
p;of these is JavaScript modules run in strict mode, which actually remo=
ves features that are problematic for the engine or make it difficult to=
 create optimized code.<br></div><div><br></div><div>Something similar c=
ould be done in PHP, and that's what the remainder of this letter is abo=
ut, but before I continue I want to make clear my vantage point: I am bu=
t a humble user of the code, I'm no expert on the underpinnings of the Z=
end 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.&nbsp; =
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.<br></div=
><div><br></div><div>So all that said, I'll begin.<br></div><div><br></d=
iv><div>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 r=
untime 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 tem=
plate engine.<br></div></div></blockquote><div><br></div><div>FYI, in no=
n-strict mode, this produces a deprecation warning that can be caught an=
d thrown from:<br></div><div><br></div><div>(fn(int $x) =3D&gt; print($x=
))(123.456); // deprecation warning<br></div><div><br></div><div>but thi=
s will work<br></div><div><br></div><div>(fn(int $x) =3D&gt; print($x))(=
123.000); // this is fine<br></div><div><br></div><div>Both of those are=
 errors in strict types, so you might be tempted to do<br></div><div><br=
></div><div>fn(int $x) =3D&gt; print($x))((int)$some_var);<br></div><div=
><br></div><div>but $some_var might not actually be an integer-like (suc=
h as null or a string that becomes zero).<br></div><div><br></div><div>S=
ome of us prefer the more strict, non-strict mode as the built-in strict=
 mode is actually ... uhh, problematic, to say the least, in some busine=
ss cases. So forcing strict mode is probably a non-starter.<br></div><di=
v><br></div><blockquote type=3D"cite" id=3D"qt" style=3D""><div dir=3D"l=
tr"><div><br></div><div>The only background compatibility break is the i=
ntroduction of three keywords: "import", "export" and "from"<br></div><d=
iv><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 .htaccess file usin=
g the default_filetype directive.&nbsp; If this directive is missing its=
 value will be "default" - the value "module" will be used to trigger lo=
ading the initial PHP file as a module, and further types could in theor=
y be introduced at a far later date.<br></div><div><br></div><div>Again,=
 this setting only affects the INITIAL PHP script file loaded by the int=
erpreter, 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.&nbsp; Files that are included with import are PHP User Mod=
ules.<br></div></div></blockquote><div><br></div><div>One of the advanta=
ges of the current autoloading file-loading system is that files are not=
 included until the are used. This allows you to run MASSIVE projects th=
at realistically only need to load dozens of files. For example, I know =
of some code-bases that have literally millions of PHP files collected o=
ver the last 15 years and hundreds of developers working on them every d=
ay.</div><div><br></div><blockquote type=3D"cite" id=3D"qt" style=3D""><=
div dir=3D"ltr"><div><br></div><div>User Module Files<br></div><div>PHP =
User Modules have the following properties (Proposed, and very much subj=
ect to change):<br></div><div>* They are code files.&nbsp; They have no =
&lt;?php or ?&gt; tags, and the inclusion of those tags is a&nbsp;parse =
exception. I know this will be problematic for PHP storm and other IDE's=
, but it's not an insurmountable problem.<br></div></div></blockquote><d=
iv><br></div><div>So, will ?&gt; work? I have turned on output buffering=
 and then just wrote out what I needed --- ie, a template, then get the =
output.&nbsp;</div><div><br></div><blockquote type=3D"cite" id=3D"qt" st=
yle=3D""><div dir=3D"ltr"><div>* If the removal of HEREDOC and NOWDOC sy=
ntax would simplify the parser, then these too&nbsp;would be removed fro=
m User Modules.<br></div></div></blockquote><div><br></div><div>Are we s=
ure we want&nbsp;<b>multiple</b> PHP parsers to maintain?</div><div><br>=
</div><div id=3D"sig121229152">=E2=80=94 Rob<br></div></body></html>
--2ac585f0f3d64c6b9bc59052ba7e44c9--