In planning my PHP projects, I continually run into the same issue. Roughly ninety percent of the best PHP libraries out there do not use namespaces. This is of course a result of namespaces being relatively new, and many projects wanting to maintain compatibility with PHP 5.2 and earlier. What this really translates into for me is, if I want to add a library to one of my projects, which are designed with PHP 5.4+ in mind, I have to manually namespace all the files in that library, else face likely code conflicts.
Now, I may not have any conflicts with the working files, if I include them into the root namespace, until I start trying to autoload. Every large PHP library seems to have its own autoloader, which is fine, until you realize that they are almost always named autoloader. This of course is the first conflict that I almost always run into. I can load multiple autoloaders, but I can’t do so if they all have the same name and the same namespace. The simplest solution is to give them all the same namespace of the vendor. This does work, but it’s a bit messy. The more difficult solution would be to implement the third party autoloader into my own autoloader. This is just too much of a pain in the ass.
You may think that at this point my solution is simple. It’s not, it’s messy, it’s ugly, and it’s downright disgusting. By doing modifying the files I run into issues when it comes to using version control. I am moving all my projects over to git, due to one of it’s awesome features of using submodules. By using submodules, I can include the repository of another library in my project, and have it keep up to date, without having to manually update it myself. The second I modify one of the files, my only option is to fork the project. What this means is, whenever a project is updated, I have to re-pull all the files downstream, and then do my modifications all over again. This is a glorious waste of time and effort. I chose those libraries because I feel that the vendors of those libraries are the best at what they do, and I don’t want to try and reproduce their work all over again. Namespacing non-namespaced code defeats that purpose, forcing me to fork their code, and hope that I don’t miss any major security updates as time goes on.
As you can see, namespacing is awesome, if everyone uses it. So long as everyone tries to be backwards compatible, and produces non-namespaced code, namespacing is a headache. It’s at this point that people will say, why not just get rid of namespaces. I will tell them, that is not the solution. Without namespaces, the conflicts I had will still be there. Namespacing fixes the conflicts. Namespacing gives code context. Context in any language, programmed or spoken, is important. Context does more than tell us what you said, context tells us what you mean. Namespaces are a step forward, the next step is to actually use them.
Mark LaDoux 