PHP 3 was released in mid-1998. Some basic object-oriented (OO) capabilities were included, more or less as an afterthought, to "provide new ways of accessing arrays."¹

No significant changes were made to the object model when version 4 was released in mid-2000. The basics of object-oriented programming (OOP) were there -- you could create a class and single inheritance was supported.

With the release of PHP 5 in 2004 there was plenty of room for improving PHP's OO capabilities. At this point, Java, the most popular OO language to date, had already been around for almost 10 years. Why did it take PHP so long to become a full-fledged OO language? The short answer is because PHP is principally a web development language and the pressures of web development have only recently pushed it in this direction.

Support for objects has been grafted onto the language -- you can choose to use objects or simply revert to procedural programming. That PHP is a hybrid language should be viewed as something positive, not as a disadvantage. There are some situations where you will simply want to insert a snippet of PHP and other situations where you will want to make use of its OO capabilities.

As I have already argued in Chapter 1, in some cases, an OO solution is the only solution. PHP 5 recognizes this fact and incorporates a full-blown object model, consolidating PHP's position as the top server-side scripting language.

Like Chapter 2, this will be a chapter of broad strokes. I'll give a general overview of how the object model has been improved, and then I'll get into the details using concrete examples in later chapters. I'll also address the issue of backward compatibility.

Chapter 2 identified access modifiers as an essential element of an OO language. PHP 5 gives us everything we would expect in this area. In previous versions of PHP there was no support for data protection, meaning that all elements of a class were publicly accessible. This lack of access modifiers was probably the biggest disincentive to using objects in PHP 4.

Every OOP language comes with some built-in classes, and PHP is no exception. PHP 5 introduces the Standard PHP Library (SPL), which provides a number of ready-made classes and interfaces. As of version 5.1, depending upon how PHP is configured, all in all, there are well over 100 built-in classes and interfaces -- a healthy increase from the number available in version 5.0.

Having ready-made objects speeds up development, and native classes written in C offer significant performance advantages. Even if these built-in classes don't do exactly what you want, they can easily be extended to suit your needs.

All OOP languages support exceptions, which are the OO way of handling errors. In order to use exceptions, we need the keywords try, catch, and throw. A try block encloses code that may cause an error. If an error occurs, it is thrown and caught by a catch block. The advantage of exceptions over errors is that exceptions can be handled centrally, making for much cleaner code. Exceptions also significantly reduce the amount of error-trapping code you need to write, which offers welcome relief from an uninspiring task. Also, having a built-in exception class makes it very easy to create your own customized exceptions through inheritance. (You'll learn how to make the transition from error trapping to exception handling in the section "Replacing Errors with Exceptions" on page 79.)

Because PHP is all about building dynamic web pages, database support is all-important. PHP 5 introduces the mysqli (MySQL Improved) extension with support for the features of MySQL databases versions 4.1 and higher. You can now use features such as prepared statements with MySQL, and you can do so using the built-in OO interface. In fact, anything you can do procedurally can also be done with this interface.

SQLite is a database engine that is incorporated directly into PHP. It is not a general-purpose database like MySQL, but it is an ideal solution in some situations, in many cases producing faster, leaner, and more versatile applications. Again an entirely OO interface is provided.

PHP versions 5.1 and higher also bundle PHP Data Objects (PDO) with the main PHP distribution. If you need to communicate with several different database back ends, then this package is the ideal solution. PDO's common interface for different database systems is only made possible by the new object model.

Given the importance of databases, we'll deal with them extensively in this book. We'll develop a MySQL database class starting with Chapter 9. In Chapter 15 we'll look at SQLite, and in Chapter 16 we'll discuss PDO.

In PHP 5 all Extensible Markup Language (XML) support is provided by the libxml2 XML toolkit (www.xmlsoft.org). The underlying code for the Simple API for XML (SAX) and for the Document Object Model (DOM) has been rewritten, and DOM support has been brought in line with the standard defined by the World Wide Web Consortium.

Unified treatment of XML under libxml2 makes for a more efficient and easily maintained implementation. This is particularly important because support for XML under PHP 4 is weak, and web services present many problems that require an OO approach.

Under PHP 4, creating a SOAP client and reading an RSS feed are challenging programming tasks that require creating your own classes or making use of external classes such as NuSOAP (sourceforge.net/projects/nusoap). There's no such need in PHP 5. In Chapter 12, you'll see just how easy these tasks are using the built-in SOAPClient class and SimpleXMLElement. Again it's the improved object model that makes this possible.

The reflection classes included in PHP 5 provide ways to introspect objects and reverse engineer code. The average web developer might be tempted to ignore these classes, but Chapter 14 shows how useful they are for automating a task that most developers approach with little enthusiasm: the creation of documentation.

In addition to built-in classes, PHP 5 also offers built-in interfaces. Iterator is the most important, as a number of classes and interfaces are derived from this interface. I'll show you how to use Iterator in Chapter 10.

Backward compatibility may be an issue if your code already uses objects. PHP 5 introduces a number of new "magic" methods. Magic methods begin with a double underscore, and this requires changing any user-defined methods or functions that use this naming convention. All of these methods will be discussed, particularly in Chapter 13. The most important ones relate to how objects are created and destroyed. The PHP 4 style of object creation is still supported, but you are encouraged to use the new magic method approach.

PHP 5 deprecates some existing object-related functions. For example,is_a has been replaced by a new operator, instanceof (see Chapter 14). This particular change won't affect how your code runs under PHP 5. If you use a deprecated function, you'll see a warning if the error-reporting level is set to E_STRICT (a useful technique for discovering where your code may need upgrading and discussed in more detail in Appendix A). In another example, the get_parent_class, get_class, and get_class_methods functions now return a case-sensitive result (though they don't require a case-sensitive parameter), so if you are using the returned result in a case-sensitive comparison you will have to make changes.

The preceding examples of changes are relatively minor and fairly easy to detect and upgrade. However, there is one change in particular that is of an entirely different magnitude.

The major change to PHP in version 5 relating to OOP is usually summed up by saying that objects are now passed by reference. This is true enough, but don't let this mask what's really at issue: a change in the way that the assignment operator works when used with objects.

Granted, the assignment operator is often invoked indirectly when an object is passed to a function or method, but objects are now passed by reference because of the implicit assignment. Prior to PHP 5, the default behavior was to assign objects by value and pass them to functions by value.

This is perfectly acceptable behavior for primitives, but it incurs far too much overhead with objects. Making a copy of a large object by passing it by value can put strains on memory and in most cases, all that's wanted is a reference to the original object rather than a copy. Changing the function of the assignment operator is a fairly significant change. In fact, the scripting engine that underlies PHP, the Zend engine, was entirely rewritten for PHP 5.

The mere enumeration of the details of backward compatibility masks what can be a highly charged issue. Whenever you change an established language, there are competing interests. In many cases you're damned if you do and damned if you don't. For example, retaining inconsistent function naming conventions may be necessary to maintain backward compatibility, but you may also be criticized for this very lack of consistency.

Of course, breaking backward compatibility means that some existing code won't function properly. In many circumstances it's not easy to decide where and when to break backward compatibility, but changing PHP to pass objects by reference is a fairly defensible change despite any inconveniences. The only thing you can be sure of is that any change will give rise to complaints in some quarter. Certainly, having deprecated functions issue warnings is one good way to give advance notice and let developers prepare for coming changes.

If you've bought this book and read this far you're obviously interested in OOP. If you know PHP already, then learning OO PHP will not be too difficult. Given the relative simplicity of PHP's object model, certainly less effort is required than for a C programmer to learn C++. Nevertheless, moving to a new language or a new version of a language entails some cost in terms of time and effort, especially if it has an impact on your existing code libraries.

We've covered some of the backward compatibility issues as they relate to OOP. Almost all procedural code will run with no changes under PHP 5. No rewrites are required, and code does not need to be converted to an OO style.

Upgrading existing applications to take advantage of PHP 5 is a different matter. In the case of some large applications, upgrading may require significant effort. Many applications will benefit by being upgraded. If you've ever tried to customize software such as phpBB (the popular open-source forum), you know that the task would be much simpler if the application was object-oriented. However, upgrading an application such as phpBB means beginning again from scratch.

And there are other considerations besides code compatibility. After learning the ins and outs of OOP with PHP 5, will you actually be able to make use of it? Are there actually servers out there running PHP 5?

As of this writing PHP 5 is hardly a bleeding-edge technology. It has been available for more than a year, and there have been a number of bug fixes. It's a stable product. Where developers have control over web server configuration there's no question that upgrading to PHP 5 will be beneficial. But developers don't always have a choice in this matter. In some situations (where the developer has no control of the web host, for instance), the decision to upgrade is in someone else's hands.

PHP is a victim of its own success. The popularity and stability of PHP 4 have slowed the adoption of PHP 5. PHP 4 is a mature language that supports many applications, open-source and otherwise. There's naturally a reluctance to rock the boat. For this reason the adoption of PHP 5 has been somewhat slow, especially in shared hosting environments.

Widespread adoption of PHP 5 will happen sooner or later, but this book recognizes that developers may need, at least for a time, to continue writing new applications that will run under PHP 4. For this reason, wherever possible, a PHP 4 version of code has been provided in addition to the PHP 5 version.

In a sense, PHP 5 just formalizes what was already possible in PHP 4. For instance, even though PHP 4 allows direct access to instance variables, when creating a class in PHP 4 it makes sense to write accessor methods for variables rather than setting or retrieving them directly. This requires a disciplined approach, but it will yield code that not only runs under PHP 4 but also will be much easier to upgrade to PHP 5. Adding restrictive access modifiers to variables will be a relatively simple task if accessor methods are already in place. Writing code with the expectation of upgrading it will also invariably mean writing better code.

That's all the talk about OOP. In the remaining chapters you're going to do OOP.

¹ See Zeev Suraski, "Object-Oriented Evolution of PHP," available at www.devx.com/webdev/

Reprinted by permission from No Starch Press -- Copyright 2006 No Starch Press. All rights reserved.