Hello all: While reading the [RFC] Union Types v2 thread and comments from Dmitry[1], and especially Benjamin[2] who suggested "building a static analysis tool which could prove that certain type checks would never fail, and prime OpCache" it occurred to me that a PHP pre-compiler could potentially be used to resolve numerous issues the community has been debating.
But first, let me define what I envision for a pre-compiler: - A command-line tool that could take a PHP file and/or application and generate pre-compiled files with an extension of .phpc or similar. - This of these .phpc files being implemented similar to .phar` files, but actually compiled to a OpCache binary form. - Pre-compiled files would be deployed alongside .php files, or optionally(?) standalone without PHP files. - Libraries and (WordPress) plugins could deliver pre-compiled files too, alongside their .php source files - Command line switches could allow for: - Compiling with or without (selected) deprecations - Selected constants defined on the command line - Packaging code on a one-to-one per PHP file, as one file per namespace, one file per app, etc. - The pre-compilation process would be able to: - Type-check everything that has type-hints - Do type checking that is too expensive to do at runtime - Pre-compiling: - Could help eliminate the complexity of auto-loading and opening many files, at least for pre-compiled code. - Would be an option for type checking and improved performance, but not be required. If the PHP community were to embrace the idea of an optional pre-compiler then we could see the following benefits: 1. Full type checking capability without any concerns for runtime performance issues related to type checking. 2. Ability to significant improve performance over time, possibly even more than a JIT model. 3. Potential to support optimized real types — as in Hack — where code needs to be highly performant 4. Ability to deprecate features for pre-compiled code while still supporting them when not precompiled. While benefits #1 to #3 are highly valuable, consider benefit #4. If we had such a pre-compiler than the concern for BC for pre-compiled code could become moot as the deprecations would not affect any existing code that is not pre-compiled. This could potentially give us the best of both worlds? Further, those most interested in deprecations and moving to enterprisey language features certainly use a CI/CD build process so it should be not problem at all for them to incorporate a pre-compile step. Lastly, having such an optional process — with its primary promoted benefit being performance — could be a great incentive for those running less strict and backwards-compatible PHP code to refactor their source code to gain greater performance. This contrasts with deprecating features and breaking BC just "because it is a better way to program." Give them a carrot rather than use a stick. So for those who know PHP's internal core code: Is there any reason this is not technically viable? And for everyone: What do you think of this as a potential future for PHP? -Mike [1] https://news-web.php.net/php.internals/107699 [2] https://news-web.php.net/php.internals/107702
