> 1) recommend all global non-namespaced code that wishes to import
> namespaced code via "use Namespace::Classname" add a "namespace
> __php__;" at the top of the file, and that the __php__ namespace be
> reserved for use by end-user applications.
> 5) namespaces provide these benefits that are not available in PHP:
> a) short, unqualified descriptive class names can be used without
> fear of conflicting with an internal class
Interesting as I was not aware before that when a namespace is active the
import goes into that namespace and not into global scope (clashing with core
classes there).
But please consider:
-- Date.php --
<?php
namespace __php__;
class Date {}
?>
-- test.php --
<?php
namespace __php__;
require_once('autoload.php'); // assume it would require Date.php when
asked to do so
print get_class(new Date());
?>
Although this code has been future-proofed by adding the "namespace __php__",
it will break if the core introduces a class named Date (will use the wrong
class!). It also breaks without the namespace, and maybe it is a mistake to
rely on autload here. But this is a case where using namespaces does not
protect you from surprises unless you explicitly import ("use") all the classes
you need. But that is not as simple as putting a namespace statement on top of
all your files to be save.
If new, future core extensions showed up in a reserved PHP:: namespace, you
would be >:-).
-mp.
