> On Jan 6, 2020, at 5:52 PM, Rowan Tommins <rowan.coll...@gmail.com> wrote: > > On 06/01/2020 21:01, Mike Schinkel wrote: >>> On Jan 6, 2020, at 5:56 AM, Robert Hickman <robehick...@gmail.com> wrote: >>> >>> Would it be worth expanding the ideas of programmatic constant >>> definition into a more general compile-time code execution approach? >> That would certainly be interesting. I do not know enough what is possible >> there to opine. >> >> It it were possible that might be the best of all worlds. >> >> Anyone with experience in that area able to comment? > > Isn't that the same as pre-processors, which elicited this response when I > mentioned them before:
As I said it my most recent other reply I said I view pre-processors as text substitution. But you might have meant something different than text substitution? What I think Robert was referring to — at least to me — was a form of pre-loading or recompiling into some form that could be referenced by the normal code, not an approach that would generate a new .PHP file. Something that can be linked via symbols at runtime. Maybe something similar to preloading in PHP 7.4, but accessible by the developer like .htacess is accessible to the developer, vs. just accessible to the system administrator: https://stitcher.io/blog/preloading-in-php-74 But I don't want to fixate on my definitions; whatever we call them is fine as long as we both understand what we are talking about. > Parse the code to an AST, allowing function calls with literal arguments > wherever a literal value would normally be allowed. Find all function calls > to something in the MACRO namespace, evaluate them, and substitute the result > into the AST. Then write the modified AST to a new PHP file, and deploy that > to your server. It is the writing of the new PHP file that I think would be a problematic. Again, from my other reply, such approaches are not composible and that is my objection to them. -Mike P.S. Please tell me you are not the guy who wrote Pre from preprocess.io, are you? :-o -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
