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
