PHP5: Coming Soon to a Webserver Near You

ADT

ADT stands for Abstract Data Types, an extension for which the source is online here. The idea behind the ADT extension is to implement in PHP some of the more unusual data types (the real Computer Science stuff) including Stacks, Binary Trees, Heaps and Graphs. Certainly these will be important if PHP wants to become a serious general purpose language, rather than one focused on Web development. And they might also open the door to new possibilities, such as building fast, pure PHP search engines.

At present, it doesn't look like the ADT extension will be available as part of the core of PHP5 (or even as a stable extension), as it’s not much more than a prototype at the moment. Other priorities (such as PHP's day job as a solution for Web programming) are taking precedent, but if you're interested in knowing more, try this presentation.

Backwards Compatibility

In general, my guess is that 90% of PHP4 scripts will be able to run under PHP5 without any modification. Of course, I haven't done any intensive tests here, but most of the new features PHP5 provides are add-ons, rather than replacements, to PHP4. The old style constructors, for example, are still supported, as is the reference operator, which is effectively ignored where objects are concerned in PHP5.

If your code is primarily procedural there should be very few problems, if any at all.

However, you will have problems if you have PHP4 classes called "abstract" or "interface". Also I noticed PHP4’s built-in "stdClass" has disappeared, which may affect some.

As a vague rule of thumb, if you've been writing code which you might describe as "pushing the limit" of PHP4's intended use, then you probably need to take a serious look the impact of PHP5.

You may also need to be careful if you're using the SAX or XSLT extensions (and DOM, as always). The switch to libxml should be invisible, but as with all things computer-oriented, you never can be 100% sure until you've tried it. Otherwise, the impact of PHP5 will (hopefully) mean business as usual.

All that said, when the full PHP5 release comes around, make sure you test your code before running it in live environment.

Making Waves

Phew! You got through all that. So what about the real question: what does PHP5 mean for PHP's future? This is my subjective, but hopefully informed opinion.

Laying it one the line, a recent comment on SitePointForums highlights a major issue with PHP today:

"The problem is that PHP desperately needs a decent class library of small, cohesive and reusable components."

This point re-surfaces as a fascinating and very insightful discussion: Java API as base for PHP library? (highly recommended reading).

At first glance, that may be a depressing thought. However, it's worth reminding yourself that despite its problems, PHP is a massive success.

Recent estimates from Zend place the number of active PHP developers at somewhere around 500,000. Back in June 2002 Netcraft's Survey placed PHP ahead of ASP (essentially making PHP the most popular technology for the Web), and since then, PHP has only continued to grow in popularity. Otherwise Adam Tractenberg, author of O'Reilly's PHP Cookbook, has a concise summary of PHP's history, "The battle for middleware: PHP versus the world" (a PDF at http://www.trachtenberg.com/PHP.pdf), which serves as a reminder of why PHP is where it is now.

But back to the "problem". From where I stand, PHP5 is all about addressing precisely this issue -- providing the basis for code re-use and component oriented design.

But PHP5 is not just a matter of a re-vamped object model. There are other signs, some part of PHP5, others surrounding the use of PHP, which indicate a very bright future.

Engine Level Standards

As you may have noticed while reading this article, I've used the word "standard" quite a bit. For an Open Source project like PHP, the development of PHP applications is fragmented. The more standards apply to the development of PHP code, the lesser will be the effort required to integrate any of the multitude of freely available PHP applications out there.

At some level, PHP developers need to consider their code in the context of how it fits with other projects. Taking this approach is like investing in your own future -- the stronger PHP appears as a technology, the better your chances of getting paid work with it. That means becoming conversant in the Object Oriented Paradigm, design patterns, and so on. Two reads well worth your time are Martin Fowler's Refactoring: Improving the Design of Existing Code, and Patterns of Enterprise Application Architecture, along with the original Gang of Four’s Design Patterns.

That said, one thing that’s obvious from the release of PHP5 is the development team’s willingness to implement fundamental standards within the PHP engine itself. Most obvious is the SPL extension, which I've already looked at, but other moves, such as the object oriented API to SQLite, and a new MySQL API called mysqli, which offers both functional and object-oriented APIs to MySQL, make me wonder whether we're on the way to seeing database abstraction at an engine level in PHP.

By implementing fundamental standards (such as Iterators) at an engine level, there's a very good chance that PHP developers will actually agree to use them, allowing development effort to be focused on implementing "architectural" classes that fit together nicely.