PHP5: Articles, News, Tutorials, Interviews, Software and more
Featured Article:
Learning PHP Data Objects
Wed, 26 Jan 2022
 Home   About   Contribute   Contact Us   Polls 
Top Tags
ajax article codeigniter conference dom namespace news onphp5 oop php5 poll prado security solar sqlite symfony unicode zend core zend framework zend platform
More tags »

Not logged in
Login | Register


Advocating Namespaces

« Exceptions in __autoload() Learning PHP Data Objects »

By dennisp on Thursday, 13 December 2007, 20:24
Published under: article   namespace   php5
Views: 8656, comments: 0

Recently there have been some thoughts expressed that suggested that namespaces support is not that important at the moment; and even that they are not needed at all. In this article, I would like to disagree with those ideas and advocate PHP5 namespaces, as well as to express some personal opinions about their implementation.

Namespaces are intended to resolve class and function name conflicts. PHP is a very popular language with millions of developers. There exist dozens of libraries, toolkits and frameworks, all of which are confined to live in the single global namespace. Naturally, name conflicts are common, especially when it comes to classes. But this is the theory everyone knows.

I am sure that lots of developers are waiting for namespaces; otherwise they would not be one of the hot topics recently.

Namespaces are not so obvious for people who generally use procedural programming. They say it's ridiculous to wrap a function into a namespace. Agreed. I personally don't think that there is any need to provide namespaces for functions wrapping, as I am only interested in object-oriented development. I came into PHP world from Java and I liked its truly OO approach. As well as its clear package-based approach. I never saw the include() hell there (there's simply no way to include a file into a .java file).

But I think and hope that those developers who usually use OOP in their PHP coding, will benefit from the introduction of namespaces. Again, simply to prevent name conflicts and better organize class files in the filesystem. Yes, I advocate the one class per file approach. This approach allows to quickly code a simplistic __autoload() function and forget about all the includes. Also, class autoloading gives obvious performance gains. In many projects, I saw that developers had a file (usually called config.inc.php) where lots of constants were defined as well as tens of files were included. Of course, only a small fraction of these is needed for a particular request, but it is much easier to include everything in one place and not to care about whether a particular include is needed at all. Class autoloading ensures that only those classes are compiled that are really needed. And this functionality is already built into PHP5.

Recently there has been a discussion about the namespaces syntax: use curly braces or not, allow multiple namespaces in a single file or not, and what to do if an included file contains another namespace declaration. These talks slow down the release of the final namespaces implementation, and I would be just happy if the namespaces served my basic requirements - allow to efficiently organize code in the one-class-per-file manner. Hence there is no need to have multiple namespaces in a file - this would make class autoloading much trickier and not that effective. The curly braces discussion would also have no point anymore: since a file can contain only a single namespace, there is no need to mark its end. Regarding include files - again, I don't see any point of including a file when every source file contains a single class declaration. However, if this is ultimately needed, then I would suggest that every include and eval() call are treated as if they were made in the global namespace; ie, if they contain a namespace declaration, then it is effective only within that file or eval().

One more important thing. Currently, PHP does not allow to use all classes from a namespace (ie, it's not possible to say use my::namespace::*). This is a very useful thing if the class relies on many classes from other namespaces. It is possible, however, to use my::namespace and then refer to classes as namespace::Class1 or namespace::Class2. But I personally would prefer the use my::namespace::* way. (The engine can simply try every use'd namespace with the __autoload() function and raise an error only after no class is found. Similarly, this routine could be applied to find out if there are more than one class of the same name use'd. In such case, the engine should also warn about class name ambiguity).

Finally, I might be accused of all these ideas being Java-like. But my answer would be "So what?". As I know, there is no code base that uses namespaces yet, so the future implementation will not hurt anyone. On the other hand, I would like a simple and clear solution - such as the one class per file is.

Related articles

Learning PHP Data Objects
Exceptions in __autoload()
i18n with PHP5: Pitfalls
SimpleXML, DOM and Encodings
PHP Version 5.2.2 Released
PHP Version 5.2.2 (RC1) Released for Testing
PHP Version 5.2.3 Released
PHP Version 5.2.4 Released
PHP Version 5.2.4 (RC1) Released for Testing
PHP Version 5.2.1 Released
Issues with Non-ASCII Chars in URLs
Clickable, Obfuscated Email Addresses
Some SEO Tips You Would Not Like to Miss
Sorting Non-English Strings with MySQL and PHP (Part 1)
Most Important Feature of PHP 5?
PHP5 More Secure than PHP4

Post your comment

Your name:


Protection code:

Note: Comments to this article are premoderated. They won't be immediately published.
Only comments that are related to this article will be published.

© 2022 onPHP5.com