On Tue, Jun 2, 2026 at 4:15 AM Derick Rethans <[email protected]> wrote:
> 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 Question - what is the performance hit of scanning the file for <?php and, if none are found, restarting the parse process in code mode? If the hit isn't significant, this might be a way forward. There is the BC break that files fed through the parser with nothing to parse will start creating errors, but that situation (a php file with no <?php at all) feels like an error state anyway. Thoughts?
