Within the PHP implementation of namespaces, these names will be ideally refactored to Zend\Db\Adapter\Mysqli and PHPUnit\Framework\Constraint\IsInstanceOf, where \ is the namespace separator. In the codebase, however, there will typically be very few references to these classes with their fully qualified name, because it is possible to import entire namespaces in a script and then use the class names directly, making the code easier to follow and unambiguous to write.

In fact, the definition of a namespace class itself does not contain its fully qualified name. For example, this would be the source file of an hypothethical MyLibrary\TypeOfComponents\MyClass class:

<?PHP
namespace MyLibrary\TypeOfComponents;

class MyClass
{
    // ...
}

The convention when writing namespace-enabled code is that of creating a folder structure that reflects the individual components of a namespace (for example, MyClass would be in the MyLibrary/TypeOfComponents directory. This helps standardizing the autoloading process.

How namespaces work

Namespaced name resolution has been retrofitted in PHP 5.3 by inserting a processing mechanism at compile time. All the references to classes and functions in a namespaced source file are parsed before the actual execution of the PHP script and substituted with fully qualified names.

But what rules does the name resolution process follow? You can better understand this process with a filesystem metaphor:

• Every name that does not start with a backslash is interpreted as a relative reference (path) from the current namespace (directory). For example, in the source code above, MyClass would refer to MyLibrary\TypeOfComponent\MyOtherClass with the unqualified name MyOtherClass. It can also refer to MyLibrary\TypeOfComponents\SubNamespace\ACollaborator with the qualified name SubNamespace\ACollaborator.
• Names that start with a backslash are always relative to the global namespace (to the root directory), and are always resolved to the literal specified value. For example, \PHPUnit\Framework\TestCase class is resolved to the fully qualified name of PHPUnit\Framework\TestCase.

Note that the name resolution process examples above are limited to classes, but the same concepts apply to methods.

Pre-PHP 5.3 code will not, of course, have any namespace defined in it and will continue to work as before, residing in the global namespace because there are no namespace keywords.

Fallback

There is however an exception to the resolution process I have just described: constants and functions that are defined in the global namespace—including all built-in PHP functions like is_array() and strlen().

If we had to refer to each function using its fully-qualified name and prefix them with a backslash every time we need to use them, our code would pretty soon become an unreadable jumble of symbols. For example, you’d have to write \strlen() in all namespaced code, because the strlen() function is defined in the global namespace, and not in the current one.

Luckily, function and constant name resolution falls back to the global namespace when they are not found in a more specific one that is currently available. Thus, you can call strlen() from namespaced code without using a leading backslash—as long, of course, as you do not have a strlen() function defined in the current namespace that will shadow the global one.

This fallback rule does not apply to classes and interfaces: SPL‘s constructs such as Iterator and ArrayObject, for example, must be written as \Iterator and \ArrayObject in namespaced code, or they won’t work.

You can think of this rule as having these functions defined in your PATH environment variable: no one refers to the ls (dir at a Windows shell prompt) command as /bin/ls.

Importing classes

Being able to refer to classes in the current namespace without their fully qualified name is a good improvement over the long class names we had to deal with before namespaces, but we can expand the name aliasing further.

Import statements that create aliases to fully qualified names can be inserted after the namespace keyword, which is always the first language construct at the beginning of the file when present. These aliases are local to the file. Consider this example:

<?PHP
namespace MyLibrary;

use ExternalLibrary\Filter\Int as IntFilter;
use ExternalLibrary\Filter\NotEmptyString;

In a source file with these use statements, you can refer to the IntFilter and NotEmptyString classes without any syntax noise. If an explicit alias is not defined, the base name (NotEmptyString) is used as a default value, and it is usually sufficient.

Again, we can extend the filesystem metaphor to cover the import functionality. Aliases can be compared to symlinks from the current directory to an absolute path: you are able to refer to the symlink with a short base name instead of using a long absolute path.

Importing class and function names makes namespace very efficient to employ. The fully qualified name of an external class is hidden from the source code and extracted at the top of the file: if it changes, it is easy enough to update a single instruction instead of refactoring large areas of code. Moreover, with this approach the external dependencies are explicitly listed in a single point for every source file.

Dynamic features

Name resolution happens at compile time; therefore, every time a class is referenced dynamically, such as when using a variable variable or passing a parameter to (for example) class_exists(), you must be a fully qualified class name:

$instance = new $class();
$boolean = class_exists($class);
$boolean = $instance instanceof $class;

In these use cases, by the time the code is executed, the resolution process will have already occurred and, obviously, the compiler will have no way of telling whether $class contains a class reference that must be resolved; therefore you must make sure that it contains a full-qualified class name in order for things to work properly.

Despite their simplicity, some of the less-obvious aspects of namespaces can be difficult to understand when you’re first starting out. If you have any other doubts, you can read the FAQ from the official manual, which contain much more code than my examples, or ask a question in the comments.

The result is that a programmer who wants to make a name for herself soon finds out that it takes an extremely thick skin to survive in this world—even if you try your best to avoid being caustic, chances are that others around you won’t. In the world of computers, people have to volume settings: loud, and extra loud. To borrow lamely from pop culture, our amps all start at eleven.

The question is: why?

Critic’s Corner

One of the things that I have learned in twenty years of attempting to program is that we’re all doing it wrong. You. Me. Everybody.

No matter how advanced the techniques that we use, there is always something that we could be doing better. Do you think that static methods are convenient? Sure, they work—but His Holiness Martin Fowler has decreed that Singletons are the correct way of handling static data. Except, of course, that he also told us that dependency injection is a much better way of handling external dependencies.

Which one is right?

The real problem is that the answer to that question is, “yes.” That’s because it lacks a specific context in which it can be inserted. Dependency injection may be the correct answers in some situations, while singletons may be perfect for your needs in others. Without in-depth knowledge of the circumstances in which a particular problem presents itself, there is no particular way to offer a definitive solution.

Meanwhile, in the Bat Cave…

While we stand and argue the finer points of computer science, we often lose sight of our primary mission: enabling processes. A programmer is first of all an artisan: proud of her work, but most productive when she is making something.

Somewhere along the lines, we’ve somehow managed to convince ourselves that we are artists. We have stopped debating differences on their merits within the context of enabling us to get things done—instead, we argue them endlessly in the abstract, as if writing code were both means and end. Like the CIO who sets a company’s IT strategy based on what’s on the back cover of the latest issue of Information Week, we’re moving from fad to fad without stopping to consider that technology is a tool and not a substitute for our own responsibility to make choices.

Meanwhile, those who somehow manage to remember that software is a tool achieve great success even if their code leaves a lot to be desired. When I open a PHP file inside the WordPress codebase, I feel like I just boarded a time machine that’s taken me back to the way we used to write PHP code six or seven years ago—and don’t even get me started on what I think of Drupal.

Yet, despite the fact that their code looks like it was written by someone who has no idea who Martin Fowler is and probably thinks that dependency injection is a medical technique for weaning addicts off of opiates, both those products undeniably work, and work well—not to mention the fact that they are very widely used.

More than that, they’re actively maintained, updated and upgraded—despite the fact that, according to what the artists tell us, software written using less-than-optimal techniques should be unmaintainable, buggy and unreliable.

If you’re agonizing over whether you’re writing good code, let me spare you the anguish: you’re doing it wrong—except if your code works, in which case you most definitely are doing it right.

Image credit: Adam Swank