> On Jan 13, 2020, at 1:31 PM, Larry Garfield <la...@garfieldtech.com> wrote: > > On Sun, Jan 12, 2020, at 6:45 PM, Mike Schinkel wrote: >>> On Jan 12, 2020, at 1:57 PM, Larry Garfield <la...@garfieldtech.com> wrote: >>> >>> Most notably, *not all code will be run in a preload context*. >> >> Can you give some concrete examples here? >> >>> Language features that only sometimes work scare me greatly. >> >> Do you have some examples of language features, from PHP or another >> language, that only work sometimes and that are known to be >> problematic. and why they are problematic? > > To use the example from the OP: > <snip> > I can see the use of that, sure. Now, what happens when the code is not > preloaded? Does that block not get run, and thus CONST_ARRAY is not defined? > Does it run on all requests if not preloaded? How does that interact with a > file that gets read multiple times? > <snip>
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. 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 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? Again, if we can I hope we can focus on concrete problems this would cause that we might be able to solve vs limiting to only abstract concerns. -------------- 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 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. Or maybe we implement ability to load Web Assembly on the server? If that were possible I could write PHP extensions in Go. :-) I think these discussions should be on a different thread though. I think we have 3 different topics here: - Userland preloading - Projection API and related - Userland loadable extensions -Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
