CHAPTER 5 ■ OBJECT TOOLS
As far as PHP is concerned, there is nothing special about this structure. You are simply placing
library scripts in different directories. It does lend itself to clean organization, and can be used in parallel
with either namespaces or a naming convention.
Naming the PEAR Way
Even if you upgraded to PHP 5.3 the moment it became available, you probably won’t always get to use
namespaces. Often employers, clients, and hosting companies are slow to upgrade, often for good
reasons. And even if your project does run on the latest version of PHP, you may find that you’re working
on legacy code. If you’re given time to recode your project for namespaces, that’s great. Most of us won’t
get that luxury.
So, without using the new namespace support, how should you address the danger of name clashes?
I have already touched on one answer, which is to use the naming convention common to PEAR
packages.
■Note PEAR stands for the PHP Extension and Application Repository. It is an officially maintained archive of
packages and tools that add to PHP’s functionality. Core PEAR packages are included in the PHP distribution, and
others can be added using a simple command line tool. You can browse the PEAR packages at
http://pear.php.net. We will look at some other aspects of PEAR in Chapter 15.
PEAR uses the file system to define its packages as I have described. Every class is then named
according to its package path, with each directory name separated by an underscore character.
For example, PEAR includes a package called XML, which has an RPC subpackage. The RPC package
contains a file called Server.php. The class defined inside Server.php is not called Server as you might
expect. Sooner or later that would clash with another Server class elsewhere in the PEAR project or in a
user’s code. Instead, the class is named XML_RPC_Server. This makes for unattractive class names. It does,
however, make your code easy to read in that a class name always describes its own context.
Include Paths
When you organize your components, there are two perspectives that you must bear in mind. I have
covered the first. That is, where files and directories are placed on the filesystem. But you must also
consider the way that components access one another. I have glossed over the issue of include paths so
far in this section. When you include a file, you could refer to it using a relative path from the current
working directory or an absolute path on the file system.
The examples you have seen so far seem to suggest a relative path:
require_once('business/User.php');
But this would require that your current working directory contain the business directory, which
would soon become impractical. Using relative paths for your library inclusions, you would be more
likely to see tortuous require_once() statements:
require_once('../../projectlib/business/User.php');
You could use an absolute path, of course:require_once('/home/john/projectlib/business/User.php');