For computing experts and coders, this is not a mystery. However, for people getting their first approach to Hypertext Preprocessor (PHP), the jump between PHP 5 and PHP 7 can seem strange. Let’s see what exactly happened with this missing version.
Why is there no PHP 6?
There is not PHP-6 because it was never released. Its original plan didn’t work as expected. To avoid confusion and not relate new developments (versions) to an unsuccessful experience and negative opinions, the decision was to jump directly from PHP 5 to PHP 7.
What was the original plan?
The functionality of the PHP scripting language made it really popular among coders. Therefore, the development of new and enhanced versions has kept going since its original release in 1994. Rasmus Lerdorf, its creator, and soon more enthusiast coders joined the effort to improve PHP.
In 2005, PHP 5 was in use, and planning for the next version’s development started. Enthusiasm was big, and plans were ambitious. PHP 6 would include native Unicode support in the API, engine, and extensions. Therefore, no external libraries would be needed, very few conversions required, and language bias would be avoided.
Besides:
- The safe_mode, together with the “register_globals” function, would be deleted.
- A new 64-bit integer type was considered.
- A traits feature for horizontal reuse of the language.
- Additional static typing features.
- A goto keyword, avoiding the goto name but adding target labels to break.
What went wrong with PHP 6?
Efforts to achieve these goals were hard. Especially the Unicode conversion took much longer than expected. And finishing this was key, the base for adding the rest of the new features. As a reference, in 2011 PHP 6 Unicode conversion task advanced around 70%.
To run a website without Unicode is hard, and your coders know it. Supporting Unicode is possible until a certain point, even in case the used language is not compatible with Unicode, but errors are easy to get. It’s not an easy task.
Accurate support for Unicode demands a language that can understand Unicode strings. And as we mentioned before, PHP 6 ambitious plan was to support it completely (API, engine, and extensions).
To achieve the goal and make compatibility possible with the International Components for Unicode (ICU) library, using the two-byte UTF-16 encoding for all the strings inside PHP was decided. It sounded logical since ICU’s system used it, and interactions inside ICU were calculated to be more than with outside players like disk files or MySQL.
Rephrasing, for coders, reading or writing a string from an outside source usually happens once. But many Unicode actions can be required on the same string. A conversion for every action multiplies the job. So to use the two-byte UTF-16 encoding looked like a proper solution, at least in theory.
Unfortunately, the decision was not as useful as expected in practice, and its cost went really high. Still, other conversions were needed to do, for instance, script code, request data, database results, etc., from UTF-8 to the UTF-16. And such conversion demanded more CPU processing. A UTF-8 string required half the memory that UTF-16 took. Besides, due to the conversion, sometimes manual checks were needed to identify the exact location of an error. It could be either in the original encoding or in the converted one.
What happened with PHP 6?
Unicode support became the PHP 6 Achilles heel. No matter the effort, opinions about it were negative. Its performance was qualified as poor, broken scripts were constant, and memory usage went high.
In March 2010, the development of PHP 6 officially stopped. Its features not related to the Unicode were transferred to the new PHP 5.4.