Introspection of php namespaces

Php 5.3 introduced the use of namespaces, a mean to organize classes and functions in packages with a common base name. Some php features that works on classes, such as Class/Object functions and variable class names, still work without confusion with a bit of attention on the data used.

Php namespaces organizes classes in a naming scheme which uses the standard separator \ to build groups and subgroups of elements, to shorten long class names and preventing naming conflicts. The classic name convention of My_Class is now becoming My\Class. Some functionalities are affected by the instantiation and I made a list of what changes when introducing the namespace keyword in your php source files.

Strings containing class names
Backslash (\ character) is the chosen separator for namespaces usage. This means that when used in a php single- or double-quoted string, it should be backslashed another time to prevent parsing: "My\\NameSpace\\Class" is a valid example.

Class/Object functions
Remember that this functions requires and returns fully qualified class names. In this group of function we find class_exists() and get_class(). Their argument is required to be a full class name (such as My\Class) and the returned values will contain full class name, for instance a call to get_declared_classes().
This is straightforward if you consider the namespace name resolving process as done at the compile time: since an argument to this functions is a literal string or a variable, it cannot be considered as a base class name of some namespace since this will involve php namespace resolutioon parsing string parameters, while it is built to work on code.
Finally, fully qualified class names never have a leading backslash. They are as simply as My\Class.

Autoloading
autoload() function and standard autoloaders pushed to spl_autoload() should work with the fully qualified class name. This is the same argument discussed on Class/Object functions.

Variable as a class name
This case is a bit trickier: again namespaced elements are resolved at compile time, so the instruction new $class is executed in the subsequent global environment, and assuming you have a fully qualified name in $class you should not prepend a backslash to make it work. Always use fully qualified names in code like this: tying $class to the executor specific namespace is not possible.

$resolvedClassName = 'NameSpace\\Other\\ClassName';
$object = new $resolvedClassName;

Standard Php Library (SPL)
Spl classes now reside in the global namespace. So every time you wrote a namespaced file, for instance a class one, you should refer to ArrayObject, Iterator etc. as \ArrayObject and \Iterator, or write a use instruction at the top of your file along with the namespace declaration.
Except if you are instantiating them via a variable class name, like in the last paragraph. If you prepend a backslash, however, it really doesn't matter and it will be stripped.

I hope these tips will help you take advantage of namespace features without wondering about what type of names should be used in coding.

Are dynamic languages evil?

Maybe unit tests for dynamic languages have to do what static language compilers already perform. But there are drawbacks like simple delegation...

The never ending religion war between static and dynamic languages has earned another debate with this post.
First, define what we are talking about: in static languages variables has a fixed type that has to be defined by the programmer when he writes the code. If we are talking about objects, you can only call methods on an object that belong to that particular class or interface. Example of these languages includes C (and its superset C++) and Java.
dynamic languages are the ones commonly used for scripting: Python and Php are the most widely spread in the open source world. In Php, $foo is a variable which type can change at any time. When you make an assignment in Python, the type of the variable matters in the subsequent executed code, but it is not checked at the compile time, primarily because there's no compiling in Php or Python (excluding the .pyc bytecode files and other stuff like Apc, whose compilation serve performance purpose and not proof of correctness).

Different architecture
Unit testing is a more radical proof of correctness of an application: it serves also to provide a specification for components, but the aspect of interest in this post is that the code is run. Static languages performs compile-time checking to catch bugs and errors even before the program loading.
However, static types checking is not enough to provide trust in code, so we have unit tests that loads the classes or procedures in question and feeds them canned data to see if they respond well.
In dynamic languages, we also have unit test (think of PHPUnit), but part of these tests are dedicated to ensure that the class does not explode. If there's a very dumb error, like passing wrong parameters to a method (string instead of array instead of object), this is discovered only when dispatching the real call, at runtime. With a single file in your editor, you can only run some syntax checking (php -l in our example).
This aspect is part of the dynamic languages architecture: the checking cannot be done a because the flow of the program will take a radical different road basing on the state of the script. In Java, a variable in a method is always the instance of the declared type; in Php it can be a string or integer or object depending on another string method value. Even the name of a method call can be a variable.

Dynamic point of view
On the other hand, these limitations on checking are the power of a dynamic language like Php, where for instance you can:
- call $object->$method()
- call $class::$method()
- code a decorator for a twenty methods interface with __call() and two lines of code.
- instance a domain model class basing on a parsed (and validated of course) string. This does not need reflection.
The decorator example is explanatory, because it's a rapid way to implement delegation using the __call() magic method. One __call() definition substitute the need to replicate all the methods signatures of the chosen class. Decorating a typical framework class of Doctrine or Zend Framework would otherwise require 100+ lines of code, making inheritance the choice even where composition would be better, to respect Lsp.
The introspection on the classes and methods provided by a dynamic language is not static checkable, but it's a very handful way to reduce verbosity and repeated code. Choose what is the right language for your job.