Le 05/06/2026 à 09:04, Alexandru Pătrănescu a écrit :
On Fri, Jun 5, 2026 at 9:07 AM Casper Langemeijer
<[email protected]> wrote:
I think this adds a lot of complexity, for dubious benefit:
not having
to start PHP code files with "<?php".
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.
As most projects use dynamic autoloading you'd have to add a stat
call for a second filename, to try both .php and .phpc files. The
performance hit for that is much bigger than any minuscule gain.
I would expect that most projects in production are using composer,
and that they are using the optimized autoloader when installing in
production.
That builds a class map to exact file, and no stat call is done.
I would say this is a problem that can be solved at autoloader level,
and I recall I did a similar implementation with what composer does,
10+ years ago, when not yet using composer.
--
Alex
A language-level syntax that is only available when you actually
implement it yourself in autoload, and that is provided by composer,
isn't a language-level syntax. It's one of the numerous critics of the
current partly-erased generics RFC, and I think having a feature opt-in
is nice, but opt-in-with-custom-autoload-implem isn't good.
Right now I'm working on a legacy codebase that doesn't use Composer.
Won't be able to use that unless I customize the autoload by myself, or
if I copy-paste some code from Composer itself, or from any other
implementation. Doesn't seem like a language improvement IMO.
