Re: Introducing compile time code execution to PHP preloading

> On Jan 14, 2020, at 7:50 PM, Larry Garfield <larry@garfieldtech.com> wrote: > I think you're still missing my point here. AST manipulation during preload would exist > to manipulate code that would be run *later*. That's the point. Sure, the code in the > run_once/preload/whatever block would be written to run in that context, but its entire point is, > presumably, to improve the running of the *rest* of the code later. And respectfully, I think I am not missing your point but that possibly you are misunderstand what I was proposing. I was not proposing *any* AST manipulation, at least not for what I was defining as "Userland Preloading." Unless you define AST manipulation as using PHP to generate code to insert literals into OpCode, but if so I think that would be disingenuous.) If you remember I said this thread had gotten to the point I am seeing these separate issues that should probably be three separate threads, which I will repeat here: 1. Userland preloading 2. Userland loadable extensions 3. Projection API and related None of the above manipulate the AST directly, although #3 would do so indirectly. (There is an argument to be made that we could split #3 into higher level APIs and lower level AST manipulation which, IMO, should be two different debates, for a total of at least 4 different debates here.) So again, when I am proposing userland preloading I am *not* as part of that proposal proposing AST manipulation, although I believe Robert Hickman may have been and maybe I should start a different thread? That is why I find it hard to believe that PHP would generate code that would fail when PHP runs that code. > That... is a completely different thing, yes, that has nothing to do with the PHP 7.4 feature > called preloading. Which would mean we've been talking about two different things this whole > damned time. *sigh* Yes. And I will take the blame for that. It did not occur to me until Robert mentioned to me that it was confusing. > No, the whole point of the FFI extension is that a user-land developer can load a .so file into > PHP directly; basically doing the lib->PHP glue code in PHP rather than in C. It does require > the FFI extension itself to be enabled, and to do safely requires using the preloader, which does > mean setting an ini setting. Interesting. So then maybe what I an asking for is to bundle FFI into core so that it is available everywhere. > Not all hosts support that. The one I work for does, which is why I've been playing with > it lately to document it all for our customers. :-) But the fact that such advanced features are > not universally available is... exactly why I am extremely cautious about having functionality that > results in subtle behavioral differences between those environments where it's available and > those where it's not. Another interesting option would be to enable loading and running of WebAssembly in core. Do you have a position on that? > The existing preload logic has no impact on behavior other than skipping the autoloader. Any > behavioral change is limited to those oddball libraries that do black magic during the autoloader, > which are already well off the beaten path. That makes it a "safe" optimization. So basically, I think this is what I have been asking for, but userland accessible. I would envision that if it modified any environment, such as setting a preloaded or error levels etc. then all that environment would reset during normal execution. > My underlying point, and then I will bow out of this thread as I am tired of repeating myself, > is that I am all for enabling more "safe" optimizations, even letting userland developers > build them, but we need to be extremely careful about them being "safe" and not "a > time bomb that will introduce subtle behavioral differences between different run modes that a > developer is not expecting,thus slowly creating libraries that will only function in one run mode or > the other". I appreciate and agree with the desire not to have unsafe issues. But as I have felt we were talking about two different things and you confirmed that, maybe what I have actually been proposing is not something we need to be at odds about? -Mike