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
