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.Cheers,
Ben
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?