PHP5: Coming Soon to a Webserver Near You

Design Patterns

Arguably the greatest success of the Object Oriented paradigm is the notion of Design Patterns. Attempting to do justice to Design Patterns in a short paragraph is not something I'm going to attempt (if you want some opinions try the Advanced PHP Forum), but, in general, the argument "design is dead" could also be applied to programming. Design Patterns represent the condensed experience of the world’s leading software architects and make it possible for developers like you and I to learn from other people’s successes, rather than wasting time painfully learning from our own mistakes.

Some say that PHP4's support for OOP was added as an afterthought. Certainly, compared to a language like Java, PHP4 implements only the most rudimentary language features to make object oriented programming possible. Perhaps an indicator of the problem is the way references work in PHP4 (more info here)–essentially, they work in a way that’s the direct opposite of a language like Java. PHP4 references have, no doubt, confused everyone from beginners taking the next step from HTML, to experienced developers coming from Java, C++, and other backgrounds.

Experienced PHP4 developers have proved themselves capable of achieving high degrees of abstraction in their designs, resulting in powerful and flexible applications such as eZ publish and Krysalis, but the degree of discipline required to reach this level of complexity is huge. What's more, where applying Design Patterns is concerned, PHP4 often requires ugly, non-standard workarounds (for example the Singleton Pattern).

This combination of factors impacts the overall "development experience" with PHP4. For a large library of classes, problems are magnified, which makes it difficult to develop really solid, cohesive libraries that stand the test of time.

Back to Reality

Now, that's all very fine in theory. Soon we may all be talking about the ROI of our content management systems (which we knocked up one evening), growing beards and developing a serious demeanour. But let me put all this another way...

Perhaps the #1 question that highlights the flaw in the way today’s PHP applications are built is "How do I integrate the rest of my site with phpBB/vBulletin/Invision Board/***insert PHP forum here***?" Generally speaking, the answer is "Hack!"

Because a procedural approach to developing PHP applications has been the most popular method used with PHP4, re-use is low. Attempting to integrate existing PHP applications with your own usually means hours of studying and re-writing third party code.

As a result, most PHP projects today begin more or less from scratch, implementing authentication systems, form handling logic, template mechanisms, and more—stuff that’s been done countless times before, by thousands of other developers. Part of the problem here is that PHP4's object model has only partially succeeded in aiding the evolution of standard application components. Repositories like PEAR and PHP Classes highlight both the success and failure of the PHP4 object model.

The bottom line is that PHP developers are wasting many hours losing their hair as they re-invent wheels unnecessarily. PHP5 may well be the hair tonic you're looking for...

Error Handling

While I'm airing PHP4's dirty laundry, another weakness is the way in which errors are typically handled.

The way your code reacts when something goes wrong (as it inevitably will) is very important. Imagine your MySQL server was momentarily "down", for example. Did your site's visitor just lose an extensive, detailed rant they were about to post in your forum?

Today’s PHP developers have adopted many different approaches to error handling. Some have developed relatively complex error handling mechanisms (e.g. PEAR Error). Others simply ignore error handling entirely, other than the occasional die() when someone goes horribly wrong.

The problem is not that you can't deal with errors at all, today, but that there is no standard, language-level solution to error handling. This means that when you use third party code, you'll often have problems unifying different error handling mechanisms. Also, your own approach to error handling may vary, so that code you wrote six months ago may not fit with code you write today.

The good news is that PHP5 has the answer!

XML Support

Given that rendering some subset of XML (e.g. HTML) is what PHP is really about, its varying support for XML leaves definite room for improvement.

Today, PHP uses three sets of third party libraries to make XML "happen":

• James Clark's Expat SAX parser
• the Gnome Project’s libxmllibrary to provide a DOM parser
• Ginger Alliance's Sablotron library for XSLT

Of the three, only the Sax extension is something PHP developers can rely upon 100%. The XSLT extension is pretty solid, although there have been occasional platform-related bugs and the extension is not widely supported by Web hosts. PHP's DOM XML extension has been the weakest link, as a result of numerous bugs and API changes, and remains experimental today.

The problem with using three separate third party libraries is the maintenance effort required of the PHP group. Expat is stable and largely unchanging but has a limited feature set, while libxml and Sablotron are still evolving. Trying to keep concurrent the PHP extensions that use them is a headache. In PHP5, the foundations have been laid to make PHP's XML support exceptional, as we'll see shortly.

With that off my chest, it’s time to take a ride with PHP5...