AW: [PHP-DEV] A rebuttal to Re: RFC: Dropping Namespace

> 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.