I think we're trying to boil the ocean here, and in doing so failing to see both the problems that need to be solved, and the possible solutions. I'd like to break things down a little bit here to address what the real problem is with a lack of namespaces in PHP.
In my eyes, there are really only two problems that arise because of lack of namespaces. The first is the one true problem we should try to solve and that is class naming conflicts. Now that PHP is growing and make inroads into big business, several large development groups may collaborate on a project. Or, they may want to use a library, only to find out a class naming conflict. After all they love about PHP, it seems like this problem makes their lives more difficult by having to manually prefix all of their classes and use those prefixes throughout their code. So, the most basic namespace proposal should just be a prefix to classes, allowing the compiler to differentiate between two classes of the same name, but from different packages. $myobj = new MySpace:MyClass(); seems good to enough to me. If this is all namespaces are, an extra label to prefix classes with - no function namespace, no import, then I say no problem. A namespace hierarchy should be problem free as well, allowing developers a little more structure. At compile time, it just results in a longer prefix than if it were a single namespace. This would also solve a slightly different problem, and that is one of perception to enterprise developers. I know that productivity wise, the above namespace proposal hardly saves the developer more time than having to hardcode prefixes into class names. But what it does do, is it makes sense to a large population of developers, especially those 'enterprise' (ie Java guys). Honestly, when I pitch how productive PHP is on my project (100+ developers), the lack of namespaces is a good jab against PHP. I know people cringe at the term enterprise a little because accomodating the enterprise doesn't always mean accomodating everyone. However, in this case, I would say we have critical mass of interest in namespaces. Having a better prefixing mechanism wouldn't break legacy code, would be optional, and would make a bunch of people happy. Now, I would assert that Java's import system (of which this proposal and others often try to follow) is only partially about namespaces, but is more of a mix of their compile system, source structure, and even naming conventions. We could do the namespace proposal and not do imports. The whole concept of Java's imports is only partially related to namespaces. There are a lot of assumptions made in Java's import system, such as a configuration setting where to look, having one class per file, having that class as the filename for that file, etc. This file including system for the compile matches up with the namespace syntax. Though there's an impression that this is a great system, I would say that it still results in confusion. The dot notation in Java can be used in the context of prefixing a class for proper compilation, accessing a function, a member variable (including those that are classes), a function, and you can string them together like mypackage.myclass.function.returnfunctionsobject.function;. There's no Java.ini to set a directory, you have to set environment variables. If we want to build a more advanced include system, then I would say that the labels should map to sub-directories in some directory specified in php.ini, and the last token in the import statement just performs a normal PHP include. E.g. if it's import mypackage.*; it would go to the predefined directory, go to the my package subdirectory, and perform an include on all the class files in that directory. Of course, we'd always want to have strict class/file names for this to work as well and only one class per file. Thanks, Al
