@VinaiKopp tweeted about an old post “PHP namespaces are flawed” by @pornelski. I don’t agree with many of the points, Vinai asked why, too long for a tweet response so here is a quick blog post instead.
I will start off saying a lot of the following is formed from my experiences from Java, but I think they are equally relevant to PHP.
You Can’t Import a Namespace: “it is debatable whether wildcard imports are a good practice” – I would go further. I would never use wildcards as adding a new class in the namespace you are importing (e.g. if a third party library) could break your code. Further, there are potentially serious performance problems as PHP would no longer know the exact name it is looking for – it would have to search everywhere for any possible match.
You can’t avoid repeating use statements: Having to type a full path each time does not make me personally blink. Use Eclipse in Java for a little while and you stop thinking about import management pretty quickly. The IDE does the heavy lifting for you, and it collapses the imports (use clauses) so you don’t even need to look at them. Eclipse works out the needed imports for you – if PHP IDEs don’t do this already, I would expect them soon to do so.
Forgotten imports/aliases: The point seems to be that you can write code with errors. I would assume a decent IDE (just like Eclipse does for Java) can know when you don’t have a required import. Eclipse can sort out the imports for you with a single command (removing unused imports, sorting and grouping them, etc). Answer seems to be use a decent IDE.
Aliases don’t work with APIs operating on classes: Personally I would have said it was a bug if they did! String arguments to functions should not be influenced by the current namespace. It would be weird to me if they did. I don’t like the idea of code behaving differently just because I rename a namespace.
PHP namespaces increase chance of collisions with reserved words: This is talking about migrating old style code to new style namespaces may fail, as your_class_name when expanded to your\class\name might have an error. True, but no reason to not have namespaces.
Nested namespaces are half-baked (sub-namespaces are not embedded): They are not sub-namespaces – you can change namespace in a file. Java does not nest package names either. Not a big deal to me. “Classes cannot simply use classes of their parent namespace” – I am not sure why that is a negative. Adding a class to a parent could break children classes if it was implemented that way. I don’t agree with the “half-baked” put forward in the comment.
Name lookup is quirky and inconsistent: But to me namespaces would be broken if when I specify a class name it could belong to several different possible namespaces. That feels wrong – I want to be explicit and unambiguous. The difference between function name resolution and class name resolution is an interesting point. I understand for backwards compatibility reasons why they had to do it, and I don’t find it confusing, but there is a slightly inconsistency there. I would have considered not supporting namespaces for functions – you have classes for that.
Fully-qualified name doesn’t work in class declaration: That does not surprise me. I would have been more surprised if the class name declaration ignores the current namespace.
Popular PHP projects overuse sub-namespaces: Seems to be a complaint about usage of a language feature rather than the feature itself. You can abuse most language features, so not a huge argument to me.
Namespace cannot be autoloaded: Namespaced classes obviously can be autloaded.
Conclusions: “I don’t think that having to use a heavy-weight IDE that parses whole project and generates boilerplate code automatically is the right solution”. I guess again I disagree. It makes developers much more productive in Java. With PHP being a dynamic language it makes it harder for the IDE to do a good job in PHP, but I don’t see why using an IDE is a bad thing.
My personal dislikes: I do have my own dislike, which is if I say Foo\Bar, it might be an absolute path or a relative path depending on context. E.g. ‘use’ you leave out a leading slash for an absolute path, but inside you must add a leading slash for it to be absolute (\Foo\Bar). It is not a huge dislike, but I would have rather having a rule such as “absolute paths always start with ‘\’; relative paths do not”.
Oh, and I don’t like the backslash character myself. I do like doing grep, awk, etc scripts across PHP code. Using backslash just makes that a little more ugly because backslash frequently has special semantics in regular expressions and other commands. And yes, that is not a very strong reason.
Alan Kent's Blog 
Thanks Alan for the great article.
One point I disagree with is writing full path each time in code (for example new /Some/Full/Path()).
I think this makes code that is hard to maintain and I think I also noticed a lot of that in Magento2 (maybe it’s temporary).
Imagine if you had to change path, you would then have to go through entire code and change everywhere. With importing namespace and using alias this would not happen. You could just change the path in import declaration and alias would remain. You could also use entirely different class.
Another thing is that full path in code tends to hide dependencies, with declarations on top of the file you can clearly see everything your class uses. As suggested here – https://mwop.net/blog/254-Why-PHP-Namespaces-Matter.html#toc_1.4
Other than, great article, actually most of the stuff in the original article are what’s useful in using namespaces.
I have coding style I prefer from my java days, but generally defer to the team as they have more php experience than I do.
I think consensus is more important than my personal opinion, so even if I personally don’t agree, I keep it to myself. We do have coding rules, but with so much code it takes time to clean up.
So I dislike full paths too, but we have duplicate class names so a naive pass to remove namespaces could easily break code. So I understand why we have the mix, even if I dislike it.
Would it make sense if I make a Github issue about it so we can have a discussion there with the rest of the team?
Feedback always welcome. Code style can become religious but feedback always read and considered. More interesting is how many others in community agree!