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
