Re: Introducing compile time code execution to PHP preloading

With regards to allowing AST introspection, john blow just posted a video on JAI which slows why it is useful. Around 11 mins into the following video he introduces a few lines into the metaprogram (the thing that interacts with the AST) which essentially 'queries' the code and reports all occurrences of pointer math. I can think of many uses for being able to query a program's source like this. https://www.youtube.com/watch?v=0mQbBayzDPI On Wed, 15 Jan 2020 at 01:57, Mike Schinkel <mike@newclarity.net> wrote: > > > 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 > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >