Since we’ve just upgraded our hosting platform to PHP 5.3 I decided to investigate Namespaces a little further. I get the basic idea behind them, but I have a question about their implementation. Basically, I’m wondering if I should prefix the namespaces with the name of a project, like so:
I’ve heard the term tons of times but like many things in IT when you find a description its all jibberish jargon which will never win any awards for english clarity or simplicity.
Simple terms? Containers that you can store your classes, constants, functions etc in. Scopes if you will. Kind of like the difference between global space and object space, where you can separate and reuse names for variables, constants, functions, classes et al. To look at in PHP they look very similar to a file system, where global space is the root directory. Crude explanation, but I think adequate?
No, not quite. Basically, when you write a page of code, you say which namespace that code applies to (you can have multiple namespaces in one file, but let’s not confuse things). Any variables, constants, functions, classes etc that you define, exist only in that namespace. So, if you accidentally define a variable called $user in two different files that are included in one another, assuming they’re not in the same namespace, they won’t interfere with each other. You then access them the same way you would a file in your filesystem, so:
If you have a global variable $user, it would be accessible from any script from \$user
If you’re in the global namespace (think in the root of your directory: \) then you can just call $user or \$user
If you’re in a namespace called foo (namespace foo; ) you would call it by \$user
If however, you have a variable called $user in the foo namespace and you’re in the global namespace, you would need to call either \foo\$user (what they call a fully qualified namespace, because you’ve referenced it from the ‘root’ global namespace) or foo\$user (just a qualified namespace, not fully qualified because you’re calling it relative to your current namespace)
If you’re in the foo namespace already though, you just refer to $user, as you would if you were in a directory called foo and just wanted the file user.
You can import namespaces and classes to appear in your current namespace in a similar way to how symbolic links work in UNIX or shortcuts in Windows.
I don’t know if that helps at all? In my directory analogy though, what I’m suggesting is in the same was as programmes are saved in their own directories on your PC (in a Windows PC they’ll be in “c:\program files\program name” most likely) when I’m creating namespaces, should I use my project name as a root namespace, rather than use the global namespace? I’m thinking JUST IN CASE
As I see it, the way namespaces were introduced in PHP is odd to the point of being almost pointless to use.
In an ideal world, you’d create a namespace and globally load classes, functions and other namespaces into it.
For instance, we both create a namespace called CMS. Fair enough, eh? The problem is, PHP has no mechanism of loading classes/namespaces into namespaces at runtime. If namespaces could be assigned as files were included the use of them would be a whole lot less messy and more manageable. I’d like to say “Take everything from \Namespace, which is loaded from this directory and put it in \Legacy\Namespace”.
On topic: Yes, I think it’s worthwhile putting your whole project in a top level namespace. That way everything is grouped together.
Thanks Tom. I must admit that the way that namespaces work in PHP seemed odd to me, especially since I’m separating my variables, functions etc in to objects and their class methods and properties. For a controlled project they don’t make a whole lot of sense to me, but in a framework, especially one with multiple independent developers etc I can see an advantage.
BTW, it was all on topic as far as I’m concerned, so thanks for all of it
