> On Jan 14, 2020, at 7:50 PM, Larry Garfield <la...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
