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 <m...@newclarity.net> wrote: > > > 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 > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
