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 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.
FYI, in non-strict mode, this produces a deprecation warning that can be caught and thrown from:
(fn(int $x) => print($x))(123.456); // deprecation warning
but this will work
(fn(int $x) => 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) => print($x))((int)$some_var);
but $some_var might not actually be an integer-like (such as null or a string that becomes zero).
Some 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 business cases. So forcing strict mode is probably a
non-starter.
>
> 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.
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 MASSIVE projects that realistically only need to load
dozens of files. For example, I know of some code-bases that have literally millions of PHP files
collected over the last 15 years and hundreds of developers working on them every day.
>
> 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.
So, will ?> work? I have turned on output buffering and then just wrote out what I needed --- ie,
a template, then get the output.
> * If the removal of HEREDOC and NOWDOC syntax would simplify the parser, then these too would
> be removed from User Modules.
Are we sure we want *multiple* PHP parsers to maintain?
— Rob