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.


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

Reply via email to