Le 28/05/2026 à 06:32, Ben Ramsey a écrit :
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