PHP Objects, Patterns and Practice (3rd edition)

CHAPTER 2 ■ PHP AND OBJECTS

Although this worked fine, it was easy to forget to add the ampersand, and it was all too easy for
bugs to creep into object-oriented code. These were particularly hard to track down, because they rarely
caused any reported errors, just plausible but broken behavior.
Coverage of syntax in general, and objects in particular, was extended in the PHP manual, and
object-oriented coding began to bubble up to the mainstream. Objects in PHP were not uncontroversial
(then, as now, no doubt), and threads like “Do I need objects?” were common flame-bait in mailing lists.
Indeed, the Zend site played host to articles that encouraged object-oriented programming side by side
with others that sounded a warning note.
Pass-by-reference issues and controversy notwithstanding, many coders just got on and peppered
their code with ampersand characters. Object-oriented PHP grew in popularity. As Zeev Suraski wrote in
an article for DevX.com (http://www.devx.com/webdev/Article/10007/0/page/1):

One of the biggest twists in PHP’s history was that despite the very limited

functionality, and despite a host of problems and limitations, object-oriented

programming in PHP thrived and became the most popular paradigm for the

growing numbers of off-the-shelf PHP applications. This trend, which was mostly

unexpected, caught PHP in a suboptimal situation. It became apparent that objects

were not behaving like objects in other OO languages, and were instead behaving like

[associative] arrays.

As noted in the previous chapter, interest in object-oriented design became obvious in sites and
articles online. PHP’s official software repository, PEAR, itself embraced object-oriented programming.
Some of the best examples of deployed object-oriented design patterns are to be found in the packages
that PEAR makes available to extend PHP’s functionality.
With hindsight, it’s easy to think of PHP’s adoption of object-oriented support as a reluctant
capitulation to an inevitable force. It’s important to remember that, although object-oriented
programming has been around since the sixties, it really gained ground in the mid-nineties. Java, the
great popularizer, was not released until 1995. A superset of C, a procedural language, C++ has been
around since 1979. After a long evolution, it arguably made the leap to the big time during the nineties.
Perl 5 was released in 1994, another revolution within a formerly procedural language that made it
possible for its users to think in objects (although some argue that Perl’s object-oriented support still
feels like something of an afterthought). For a small procedural language, PHP developed its object
support remarkably fast, showing a real responsiveness to the requirements of its users.

Change Embraced: PHP 5

PHP 5 represented an explicit endorsement of objects and object-oriented programming. That is not to
say that objects are now the only way to work with PHP (this book does not say that either, by the way).
Objects, are, however, now recognized as a powerful and important means for developing enterprise
systems, and PHP fully supports them in its core design.
Objects have moved from afterthought to language driver. Perhaps the most important change is
the default pass-by-reference behavior in place of the evils of object copying. This is only the beginning
though. Throughout this book, and particularly this part of it, we will encounter many more changes that
extend and enhance PHP’s object support, including argument hinting, private and protected methods
and properties, the static keyword, namespaces, and exceptions, among many others.
PHP remains a language that supports object-oriented development, rather than an object-oriented
language. Its support for objects, however, is now well enough developed to justify books like this one
that concentrate on design from an exclusively object-oriented point of view.