I won't go into detail here, as this topic has been discussed a thousand times on internals. Although prefixing all of your classes works, it still is a PITA. In Stubbles, we are prefixing all our classes with stub, which is fine, as it is a kind of funny prefix, but there are some cases, where this really sucks.
In our implementation of annotations (stay tuned for a tutorial on annotations), every annotation is converted to an object. In our first implementation, the class name had to be the same as the annotation name, but this leads to annotation names that aren't that beautiful to read The XMLSerializer component allows you to use the annotation @XMLTag to specify how an object should be serialized to XML. But the classname XMLTag should not b used as everybody could imagine a future xml extension grabbing the class name. To overcome this drawback, the annotation parser will pre- and postfix the annotation names, so the annotation @XMLTag loads a class called stubXMLTagAnnotation. Namespace support would help us get rid of these little annoyances, as we could import the XMLTag class from the package net.stubbles.xml.annotations. So unless someone comes up for a good reason against namespaces, they will hopefully be part of PHP 6.
BTW: Please spare me the "PHP is not Java" comments, as I already know this.
Wishlist pt 3 opposed: specifications instead annotations
In part three of his wishlist for PHP 6 Stephan wrote that he would like to see annotations built into PHP 6 directly. I disagree with him about that. Annotations can be done in userland, without any problems. He already gave some examples of projects tha
Weblog: Stubblog Tracked: Feb 25, 15:42
My wishlist for PHP6, pt5: ext/phar
To ease the deployment of Stubbles applications and new versions of the framework, Frank "invented" the Stubbles Archive (also referred to as STAR). This allows us to create a single file, that contains all PHP class files as well as other resources (like
PHP may not be Java, but it could sorely use this function. The ability to work in a non-faux namespace would be a heaven-sent.
Namespaces are absolutely necessary. I know of another framework that is used in our company which has about 1000 classes in its freely available version and another 5000 classes for the internal part. The more classes they add the more likely are class name clashes. Prefixing will surely not help in this cases.
I agree that namespaces would be a great thing for PHP. The next step would be moving all of the PHP extensions into their own namespace.
I also remember seeing somewhere that PHP6 would implement namespaces but only for classes (I don't know where I saw it, so correct me if I am wrong). I think being able to put functions into a namespace would also be a "good thing". That way it would be possible to move all of the functions in each extension into their own namespace and finally clean up the global namespace.
If it is only implemented for objects, then why don't we make a push for a String object with all of the string functionality in it. And do the same for all of the other extensions that have a ton of functions filling up the global namespace. It would also make it easier for code completion in IDEs to know that they are working with a String and to only show completions for that type of object, etc.