Top Tags
article
book
conference
mysql
mysqli
news
onphp5
oop
pdo
php5
poll
prado
security
solar
symfony
unicode
zend
zend core
zend framework
zend platform
More tags »
Not logged in
Login |
Register
|
Advocating Namespaces
By dennisp
on Thursday, 13 December 2007, 14:48
Published under:
article
namespaces
php5
Views: 1797, comments: 3
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
PHP5 More Secure than PHP4
SimpleXML, DOM and Encodings
i18n with PHP5: Pitfalls
Exceptions in __autoload()
PHP Version 5.2.4 (RC1) Released for Testing
PHP Version 5.2.3 Released
PHP Version 5.2.4 Released
Learning PHP Data Objects
PHP Version 5.2.5 Released
PHP Version 5.2.2 Released
Most Important Feature of PHP 5?
Some SEO Tips You Would Not Like to Miss
Clickable, Obfuscated Email Addresses
Error On devzone.zend.com
Sorting Non-English Strings with MySQL and PHP (Part 1)
PHP Version 5.2.1 Released
PHP Version 5.2.2 (RC1) Released for Testing
Comments
|
#1
|
By
dennisp
(editor)
on Saturday, 15 December 2007, 14:27
For those who might haven't noticed already, PHP documentation has been extended with a section on namespaces, but it states that the section is experimental and subject to changes. You can browse the docs here: http://docs.php.net/manual/en/language.namespaces.php
|
|
#2
|
By
nhm tanveer hossain khan (hasa
on Monday, 21 January 2008, 17:41
i wish this will help to stop using Zend_Module_Class type convention.
best wishes,
|
|
#3
|
By
Anonymous
on Monday, 18 February 2008, 00:02
I totally agree on the importance of having namespaces in php.
But I think you're considering the feature on a too personal way, with which I mean you're considering only your needs/taste to choose how the feature should behave. Of course you're just expressing your opinions, I'm not complaining, I'm just making some considerations.
I'm talking of course of the multiple namespaces per file + curly brace issues.
To make things short, let's put it this way: let's say half percent of people wants one namespace per file and the other half instead wants multiple namespaces (note that 'multiple' means also 2 or 3, not necessary 100). Now if you have multiple namespaces with curly syntax and you want to stick to 1 ns per file, what would that mean to you? Just to replace the ';' with an open curly brace and add a closed curly brace at the end of the file; now you're totally free to use just a single namespace per file, with only a very little annoyance of putting a closed brace at the end of the file. Instead think about the other half percent of people who wants multiple namespaces; if you implements per-file namespaces, they'll have no chance to write code as they like because there won't be the possibility to do so. Thus they'll be a lot more disappointed in not having that feature at all than the other half who would just have the annoyance of an additional curly brace.
I hope all of this makes some sense.
|
Note: Comments to this article are premoderated. They won't be immediately published.
Only comments that are related to this article will be published.
|
