Cracks in the Foundation
PHP has been around for a long time, and it's starting to show its age. From top to bottom, the language has creaky joints. I've decided to take a look at how things got to this point, and what can be (and is being) done about it. I start out pretty gloomy, but bear with me; I promise it gets better.
In the Beginning, There Was Apache and CGI
And there was much rejoicing.
In 1994, Rasmus Lerdorf created the a€oPersonal Home Page Tools,a€¯ a set of CGI binaries written in C. These tools looked little-to-nothing like the PHP we know today. Embedded in html comments, and using a syntax bearing no resemblance to C, they still contribute one critical principle to modern PHP; it just worked.
PHP is a language of convenience. It was built with the idea that anyone could toss together a few lines of code and have a working CGI script, without having to worry about the server interface, the cryptic syntax of Perl, or the pitfalls of C. It's a great idea, in theory, and for the most part, it's worked very well in practice.
Unfortunately, nothing's perfecta€‰-a€‰PHP included. Over time, PHP has suffered everything from security failures to bad design decisions. Some of these problems were avoidable, but others weren't.
Backward Compatibility Is a Female Dog
Backward Compatibility (or BC) is the bane of every library and app writer in existence. It stifles improvements, holds back innovation, promotes unsafe practices, frustrates users, and slows development. PHP, being a language intended for beginners, suffers from it even more than most.
When BC is broken, apps break. Operating system vendors who shipped the new and improved version of PHP tend to come under fire for having a broken system, even though they did nothing wrong. More often, the writers of the apps are vilified for not providing working software, despite having done nothing but follow the manual.
Sometimes, the source of the problem is correctly identified, and the PHP developers are berated for trying to make a better language. No matter who takes the blame, though, one thing remains constant; users rarely understand anything other than a€oit's broken!a€¯ They don't care whether the new version is better. The old one worked. They want it to keep working. It's a reasonable expectation.
Unfortunately, with a programming language, it's often impossible to meet that expectation without sacrificing features, safety, or speeda€‰-a€‰usually more than one of these.
PHP 4.4 was released to fix a bug that caused memory corruption when references were misued. The fix changed the internal API, forcing every extension module to be rebuilt. Unfortunately, rebuilding extensions can be an arduous process in some environments. Some extensions don't come with source code. Others are ancient, and code that managed to struggle along finally stops compiling cleanly. Vendors (such as those who provide various flavors of Linux) who ship packages have to rebuild and test not only PHP itself, but also every extension they ship before pushing to their repositories.
The results of all this are twofold. First, almost everyone holds off on updating to the new version to avoid the work and cost involved in fixing the problems that arise, leaving them all running a version with publically disclosed memory corruption bugs. Second, PHP itself is discouraged from making similar changes in the future, lest adoption of compatible fixes be slowed. It only gets worse when the change breaks source compatibility, forcing app writers to change their code even after the vendors catch up.
All of this is bad enough when the change is essential for whatever reason. It's far worse when the compatibility break is the result of bad choices or poor planning.
Innovations Are the Devil's Playthings
There are several examples in PHP's history of changes that were made by well-meaning, forward-thinking developers who were trying to make PHP better, only to be shouted down because of the trouble it would cause to implement them, or, worse, to actually make the change and suffer the chaos that ensued, because they didn't realize how far the effects would reach.
A recent example is a change in the behavior of the is_a() function between versions 5.3.6 and 5.3.7. is_a() used to allow a string parameter as its first argument; it was changed so that it would call the autoloader when passed a string referring to a class that doesn't exist. The new behavior was technically correct and consistent with the is_subclass_of() function, but calling into the autoloader when it previously hadn't caused a great deal of working code to break. Several PEAR packages st
Truncated by Planet PHP, read more at the original (another 10340 bytes)