On Thu, 28 May 2026, Alex Rock wrote: > Le 28/05/2026 à 06:32, Ben Ramsey a écrit : > > On 5/27/26 23:02, Hendrik Mennen wrote: > > > > > > 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. > > 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 think this adds a lot of complexity, for dubious benefit: not having to start PHP code files with "<?php". cheers, Derick
