30 Jun
Namespaces in PHP? Why *wouldn’t* you want them?
Earlier today I say the following tweet on the-often-down-but-always-interested Twitter from Matthew Weier-O’Phinney:
“What issues to _you_ see with using namespaces in PHP? Start blogging!”
Since I am one who likes to share his opinion on a wide variety of topics, I thought this is a good one to prompt discussion.
Namespaces are expected to be a feature in future releases of PHP. I’m an outsider when it comes to tracking the going-on in the world of PHP internals. So, because of that, I’m not going to comment on the actual syntax of how namespaces will be implemented or it’s impact on internals. That’s not really important as far as this particular discussion goes.
Imagine if you will that you are the user of a web application framework that allows you to easily use third-party libraries by dropping them into a specific location in your application structure. You go to use it and…what the fuck?!? Class name conflicts?!?!? ARRRRRRGGGGGGGHHH. You proceed to post to the mailing list for said framework, complaining bitterly about how you cannot use your favourite library with this stupid framework. Some grumpy guy from Canada flames you in response and it spirals down from there into oblivion.
There are many programming languages that support namespaces, but PHP was not one of them. Why are namespaces so important? They can help to solve the exact problem mentioned in the paragraph above. Why *wouldn’t* you want such a thing?!?! You can have 5 classes with the same name in 5 different namespaces and everything will be just fine. Except for the fact you have 5 classes with the same name. That’s not good design, but namespaces would let you do that.
So, to go back to our little framework example for a minute, the framework could assign itself a namespace (oh, I dunno, like ‘Cake’) and if you happen to want to use a 3rd-party library with your application that has a class with the same name, it’s all good…as long as you didn’t put your own code in the same namespace.
So, to answer Matthew’s original question: I cannot think of any reason to NOT have namespaces in PHP.
Article Tags >> PHP
Posted by Matthew Weier O'Phin on 30.06.08 at 11:28 am
BTW, Chris, you may also want to read my blog posting on the subject, and some of the potential issues we’re seeing in Zend Framework with migrating to true namespaces from the pseudo-namespaces we already currently employ: http://weierophinney.net/matthew/archives/181-Migrating-OOP-Libraries-and-Frameworks-to-PHP-5.3.html
Posted by Brian D. on 30.06.08 at 11:28 am
I’m with you on this one, Chris! I’ve not really kept up with internals, either, but on PHP Planet and elsewhere I’ve not understood why it’s even an issue.
Posted by Chris Hartjes on 30.06.08 at 11:28 am
@Matthew
Just read the blog post and some of the issues you are talking about seem to be easily solved. Not trivial, as they require some refactoring work of existing code, but easily solved. These issues will come up more and more once namespaces actually hit, and people will blame the wrong things.
Posted by Alex on 30.06.08 at 11:28 am
I think namespaces are (a little) useful only to library- and framework-developers.
As a “frontend-programmer” maybe I will never use them, because “explicit is better than implicit”, so I will end up writing Namespace::Subspace::Class::someMethod(), exactly as I am doing now, writing Namespace_Subspace_Class::someMethod()
Even in Python and Vala I always write the full class “path” when instantiating.
The problem arises when you have different classes with the same name in different namespaces, and you import them all. You have to check every namespace for collisions with others, and risk those collisions to be introduced in a later version of the library.
Or you end up having a (possibly long) list of “import Foo:Bar:Baz as Baz1; import Bee::Bur::Baz as Baz2;”.
This also lowers the value of __autoload(), which I use extensively with PEAR-like “namespaces”.
Bye.
Posted by Stickymaddness on 30.06.08 at 11:28 am
Well said Chris, you pretty much summed up what I thought when I first heard about namespaces being supported in php6. IMHO it’s something that would be a great addition to php. I’m surprised how anti many people are to new php functionality such as namespaces or the proposed alternate array declaration syntax.
Posted by Chris Hartjes on 30.06.08 at 11:28 am
@Alex
I understand what you’re getting at, as any feature in any language can be abused if you’re willing to try hard enough.
I don’t quite follow your second comment though. If you have classes with the same name in two different namespaces, why do you need to check for collisions? As long as you specify the namespace when calling those classes, everything should be fine.
Am I misunderstanding your question?
Posted by Travis Swicegood on 30.06.08 at 11:28 am
@Chris - the problem is when you do a ‘from foo import *’ style import, something that I’m relatively certain isn’t possible in PHP 5.3 for the reason of the problem is introduces. What happens when namespace foo and bar both have a Foo class? Collisions occur and you get errors.
As for the nay-sayers, the problems I’ve heard have all revolved around the half-attempt to implement them and the fact that they actually end up implementing what the Java world calls a package and what Python does with location based modules. It’s been more a matter of semantics, not whether or not namespaces should be there.
Posted by ken on 30.06.08 at 11:28 am
“Namespaces are expected to be a feature in future releases of PHP.”
Might want to reword that
http://php.net/namespaces
“Namespaces are available in PHP as of PHP 5.3.0.”
Posted by Chris Hartjes on 30.06.08 at 11:28 am
@Travis
Thanks for pointing that out to me. Once namespaces are available I’m sure I’ll experiment with it. Maybe it’s one of those things where the name confuses things. Calling it ‘namespaces’ makes sense to me, but I’m more sensible than some more, shall we say, militant developers.
@ken
Well, it wasn’t that long ago that they weren’t going to but namespaces into 5.3, so I preferred to take the safe route.