Optional pre-compiler for PHP8?
| From: | Mike Schinkel | Date: | Sun, 27 Oct 2019 02:12:35 +0000 |
| Subject: | Optional pre-compiler for PHP8? | ||
| Groups: | php.internals | ||
| Request: | Send a blank email to internals+get-107706@lists.php.net to get a copy of this message | ||
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