# [Pre-RFC] Pure-code source files via .phpc extension - Thread: https://externals.io/message/131154 - Original archive: https://news-web.php.net/php.internals/131154 - Started by Alex Rock on 2026-06-05T11:57:38+00:00 - Messages: 1 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #131154 — Alex Rock — 2026-06-05T11:57:38+00:00 URL: https://externals.io/message/131154#131154 Le 05/06/2026 à 09:04, Alexandru Pătrănescu a écrit : > > > On Fri, Jun 5, 2026 at 9:07 AM Casper Langemeijer > wrote: > > > > […] > > 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.