Re: [Pre-RFC] Pure-code source files via .phpc extension
| From: | Alex Rock | Date: | Thu, 28 May 2026 06:36:15 +0000 |
| Subject: | Re: [Pre-RFC] Pure-code source files via .phpc extension | ||
| References: | 1 2 3 4 5 6 7 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-131032@lists.php.net to get a copy of this message | ||
Le 28/05/2026 à 06:32, Ben Ramsey a écrit :
On 5/27/26 23:02, Hendrik Mennen wrote:I think this can be summarised with this: * File extension cannot have a "meaning" for the engine, as the engine does not care about it at all in the first place * All SAPIs will consider a "normal PHP file" as default input, could it be CLI, mod_php for Apache, or anything else (even FrankenPHP) IMO this means that the default entrypoint for "parsing and executing PHP files" for all SAPIs must not change, but /might/ either be complemented with a boolean arg for "pure PHP"/"no <?php ?> tags" , or the engine must provide another public entrypoint for this that SAPIs could implement or not. An environment variable could be even used for that, and be included in the engine by default, so that all existing SAPIs could be updated at lower cost, but the variable name would have to be checked in all existing Composer packages (something like "PHP_INPUT_PURE=0|1" , or similar, TDB anyway), and would only be used for *first included file*. Any subsequent call to "include/require" would still behave as before, to avoid BC breaks. And after that, to make use of this feature in userland projects, I would suggest an "include_pure" (and its "require" + "_once" variants) global keyword, to keep full compatibility everywhere. WDYT?I am trying to understand whether your objection is to extension- based dispatch specifically, or to the broader idea of the engine making this decision at all.I don't have a strong objection to the engine making this decision, but I'd like to hear from others first. Cheers, Ben