PHPBuilder - Object-Oriented Features New To PHP5 Page 2 Page 2

RSS Twitter

Object-Oriented Features New To PHP5 Page 2 - Page 2

by: PHP Builder Staff
February 1, 2008


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

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 meth- ods 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.

Pass By Reference

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.


In PHP 4 it's possible to pass objects by reference using the reference operator (&), and in fact it is good programming practice to do so. Needless to say, this use of the reference operator becomes entirely superfluous after upgrading to PHP 5. We'll discuss the implications of this change in Chapter 13, in the section "__clone" on page 116.


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.

Where to Go from Here

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, mov- ing 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 sig- nificant 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?

Adoption of 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 config- uration 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.


Other web hosting options have been much quicker to adopt PHP 5. The various virtual private server (VPS) hosting options usually include PHP 5, as do dedicated hosts. As a more secure and increasingly inexpensive hosting option, VPS is becoming much more popular.


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.
This chapter is excerpted from Object-Oriented PHP: Concepts, Techniques, and Code from NoStarch Press.

« Previous Page

Comment and Contribute

Your comment has been submitted and is pending approval.




(Maximum characters: 1200). You have characters left.