On Thu, Jun 27, 2024, at 09:41, Rob Landers wrote:
> 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.
If you want to see what I mean:
non-strict: https://3v4l.org/kZ09l
strict: https://3v4l.org/5kVSG
— Rob