Re: Initializing constants once, with code?

From: Date: Tue, 07 Jan 2020 01:25:20 +0000
Subject: Re: Initializing constants once, with code?
References: 1 2 3 4 5 6  Groups: php.internals 
Request: Send a blank email to internals+get-108020@lists.php.net to get a copy of this message
> On Jan 6, 2020, at 5:52 PM, Rowan Tommins <rowan.collins@gmail.com> wrote: > > On 06/01/2020 21:01, Mike Schinkel wrote: >>> On Jan 6, 2020, at 5:56 AM, Robert Hickman <robehickman@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

« previous php.internals (#108020) next »