> 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

Reply via email to