On Mon, Jan 13, 2020, at 1:26 PM, Mike Schinkel wrote: > Thanks so much for going into such detail. It really helped me > understand your concerns. > > I have been planned to propose an alternate to `static_run` because it > did not seem to me to be an ideal solution. And my proposal would not > have included modifying the AST per se, even though I think that could > be beneficial. Instead it would just be focused on userland preloading > (vs. system admin preloading.) > IOW a preload feature that does not require restarting FPM but could > instead be controlled by the userland developer.
I defer to Dmitry on whether such a thing is reasonable. My engine knowledge is far too paltry to comment. > But before I introduce that I want to better understand why you think > having things that can only run during preload and having things that > can only run during runtime would be a bad thing. To me it seems like > a benefit. Preload vs. runtime are two different contexts. Having > different behavior for different contexts only makes sense IMO. Look > at CLI vs. FPM contexts: > > - https://stackoverflow.com/a/25653068/102699 That's slightly different, as code will still execute in both contexts. And most of those differences are related to how PHP interacts with the outside world, in two different definitions of "outside world". To illustrate my point, though... Well, that explains why my last attempt to use STDOUT and STDERR in a non-CLI context failed without explanation! TIL... > I get your concern about recursion, but if that kind of issue is really > a concern I don't see why we could not artificially limit recursion on > preload to a configurable amount, with 100 being the default? It's not recursion itself that's an issue. It's that the behavior of the code changes between preload and non-preload contexts in subtle, non-obvious ways. I don't mean a recursive function that runs during preload. I mean if a function that runs in a normal request is written recursively, it will fail at high recursion levels only if the file it is in was not preloaded. So whether or not foo.php was run through opcache_compile_file() changes when and how code in that file will fail. That's the situation we want to avoid like the plague, IMO. > Separately I think it would make sense to provide a set of APIs to do > the most commonly needed things that people might want to modify the > AST for. > > One example that I could envision that would make sense for preload but > probably not for runtime is an extension of the Reflection API that > would allow code to define classes, interfaces, traits, functions, etc. > Here is something I mocked up that I called "Projection" to illustrate > that concept: > > - https://gist.github.com/mikeschinkel/e07eb14a34ce83a96198744e18b0c961 I've seen similar concepts for code-generation libraries. I've even written a very basic one at one point. That seems orthogonal to whether the end result is writing the generated code to disk or compiling it directly into memory. If we do make runtime code generation a first class citizen then some sort of API like that would be a good idea (as the alternative is to build a string and run eval()). > -------------- > > I do completely see your points about the AST and most PHP developers. > > The unfortunate problem with PHP is there is no way to use 3rd party > code to extend PHP w/o being able to reconfigure the server by adding > extensions. It would be nice if we could come up with a way for 3rd > party developers writing in C or another language — people who are more > likely to test their code before distributing it — to extend PHP such > as by generating OpCode files that a userland developer could load. That... sounds a lot like the new FFI extension? Write code in C or Rust or anything that can produce a .so file, plug it into PHP, go? There's a whole lot of caveats on that, of course. I'm working on a blog post series on that very topic at work, so stay tuned if you're interested... :-) --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
