--- title: "" url: https://www.exakat.io/16376-2/ date: 2026-09-04 modified: 2026-09-04 author: "dams" description: "I Have a Dream of a PHP Preprocessor What if PHP could be faster, stricter, and more expressive, without waiting for PHP 9? What if we could preprocess PHP code..." categories: - "Code auditing" tags: - "php" - "preprocessor" image: https://www.exakat.io/wp-content/uploads/2026/09/tools.320.jpg word_count: 1300 --- # # I Have a Dream of a PHP Preprocessor What if PHP could be faster, stricter, and more expressive, without waiting for PHP 9? What if we could preprocess PHP code into something more optimized, more elegant, or even a completely new dialect? The name itself hints at the possibility: **PHP: Hypertext Preprocessor**. But here, we’re imagining a preprocessor *for PHP itself*. This is the dream of the PHP preprocessor: a tool to transform PHP code before execution, adding macros, type safety, or even a new syntax. The idea is to automate tightening at the source code level, so developers don’t have to do it manually. Over the years, at least five brave souls tried, and almost succeeded, in making this happen. Their attempts may not have changed the world, but they proved that innovation is always worth pursuing. Let’s take a whimsical tour of their journeys, with real examples of what they aimed to achieve and where they ran into truly difficult problems. Then, let’s gaze into the crystal ball: what would a PHP preprocessor look like today? ## Attempt #1: PHP-preprocessor by gizmore **Goal:** Create a preprocessor that adds macros, compile-time evaluation, and even a new syntax layer to PHP. [Gizmore’s php-preprocessor, or PP](https://github.com/gizmore/php-preprocessor), was an ambitious attempt to give PHP compile-time superpowers. It promised: - **Macros** for repetitive code blocks. - **Compile-time evaluation** of expressions. - A **custom syntax** for easier metaprogramming. For example, imagine writing a macro to auto-generate getters and setters: This would be transformed into: The idea was to reduce boilerplate and make PHP feel more like a language with first-class metaprogramming. However, PHP’s dynamic nature made it hard to predict macro behavior: static analysis could be bypassed at runtime. The tool remained a fascinating experiment. ## Attempt #2: PHP Preprocessor by ircmaxell **Goal:** Create a preprocessor that adds compile-time optimizations, strict typing, and better error messages. In 2016, [ircmaxell’s PHP Preprocessor](https://github.com/ircmaxell/php-preprocessor) aimed to make PHP faster and safer by preprocessing code into optimized, strictly-typed versions. The goals included: - **Enforcing types at compile time** (e.g., ensuring a function only accepts integers). - **Optimizing loops and function calls** based on static analysis. - **Adding better error messages** for common mistakes. For example: The preprocessor caught the error before runtime, making PHP feel more like a statically-typed language. Ultimately, the complexity of integrating this into existing PHP 7 projects proved to be a major hurdle. ## Attempt #3: PHP Plus by stevenkellow **Goal:** Create a stricter, more modern dialect of PHP, with better type handling and syntax. [PHP Plus](https://github.com/stevenkellow/PHP-Plus) was designed as a stricter, more modern version of PHP. It introduced: - **Stricter type coercion** for better predictability. - **A new syntax** for arrays and objects. - **Better error handling** for undefined variables. For example, PHP Plus aimed to allow: And for functions: The project started in 2016, and version 2 was released in the last days of August 2026. It may be time to take a closer look. ## Attempt #4: PHP+ Proposal (InfoWorld, 2011) **Goal:** Create a new, stricter dialect of PHP called PHP++. In 2011. InfoWorld’s [2011 article](https://www.infoworld.com/article/2262496/php-plus-p-proposal-would-create-a-stricter-dialect.html) proposed PHP+ (or PHP++) as a stricter dialect, with: - **Stricter type checking**(no more silent type juggling). - **A cleaner syntax** for arrays and strings. - **Better error handling** for undefined variables and functions. For example, PHP+ would: And: The proposal was bold at the time of writing, and it remained mostly a thought experiment. It included early assessments from Zeev Suraski about feasibility and ended without support from the PHP Group. Interestingly, many of its ideas were later adopted in PHP 7 and 8: strict operators, typed variables, and more. Again, being stricter about coding is an important aspect of a preprocessor. ## Attempt #5: Plus-1 by Nuno Maduro **Goal:** A preprocessing tool that adds modern features (like arrow functions, typed properties) to older PHP versions. [Nuno Maduro’s Plus-1](https://github.com/nunomaduro/plus-1) was a transpiler for older PHP versions. It aimed to: - **Add arrow functions** to PHP 5.6+. - **Support typed properties** before PHP 7.4. - **Enable modern syntax** for older projects. For example, you could write:`php $getUsers = fn(array $filters) => User::where($filters)->get(); `And have it automatically transformed into:`php function ($filters) { return User::where($filters)->get(); } `Plus-1 was a pragmatic way to bridge the gap between PHP versions: use modern PHP syntax on older PHP versions and transpile it to the target version. PHP’s rapid evolution made it obsolete. There might also be a philosophical argument: instead of adapting modern PHP features to older engines, why not adapt older codebases to modern PHP features? That would help with PHP migration toward newer versions. That might be a consideration when preparing new PHP versions: what abandoned PHP features from previous versions can be transpiled to a new PHP version? ## So… What’s Relevant Today? All five attempts eventually stopped. It’s not a failure, though there are no actual successes either. They didn’t stop because the idea was bad. They stopped because PHP itself evolved. The PHP core team added many of the features these tools aimed to provide: strict typing, arrow functions, typed properties, and even JIT compilation. So, why build a preprocessor in 2026? What is left to experiment with? Because innovation isn’t about winning: it’s about experimenting. A modern PHP preprocessor in 2026 could focus on: - **Generics**: Of course. This feature is still in high demand for PHP. With a preprocessor, you could simulate them today. And then, you could go further with [dependent types](https://en.wikipedia.org/wiki/Dependent_type). - **Simplicity**: Making PHP more like its early, forgiving self, even in stricter contexts. You have a better view of what should and shouldn’t be done: can we encode that in the syntax? - **Leaner and fitter**: Reduce boilerplate by offloading it to the preprocessor. No need to write getters, setters, and withers: one attribute and let the engine produce it. Less code for you to read, and for AI too! - **Extra strict**: You like strict code? Go all in with mathematically provable code that cannot fail, right from the start. It might go against business rules that need to be flexible and sometimes fuzzy, so where is the middle ground? - **Validation**: Try new approaches before they get an RFC and into the language itself, like experimental syntax, macros, or standardization of function names (`str_len()` and `str_join()`, anyone?). Just compare PHP to other languages and bring in more ideas! - **Operators**: Add more operators with strange Unicode symbols (≣ ≩ ≶ ⊂ ⊗ ⊞), include imaginary numbers, tetration, Roman numerals, and quaternions... OK, you get the point. ## The Lesson: Innovation is Always Worth It The attempts to build a PHP preprocessor may have faded into history, but their spirit of experimentation lives on. Innovation isn’t about creating the next big thing; it’s about pushing boundaries, trying new ideas, and learning from failure. Sometimes, you have to learn what you *can’t*do, because what’s left is what you *can* do.