As may or may not be evident, my current professional programming is largely PHP for a transportation company. As such, it obviously behooves me to keep abreast of changes in the world of PHP. The next version of PHP, PHP 6, is set to come out with one major feature that I have personally wanted: namespaces. No language that is used for large scale development can really live without it. You can hack your way around it, but, in the end, you are using namespaces (or packages, or assemblies, or whatever the name du jour is), you are just using them poorly. A case in point is the ubiquitous mysql extension. Every function begins with the prefix mysql_. The reasons are obvious. If you just say query('select...') there is no guarantee that this will not clash with some user defined function. In addition, how many database systems wouldn't want to use this name? Which is the problem. The chance for conflict is simply too large. So, they define a namespace mysql where the ad-hoc implementation for namespaces simply involves tacking mysql_ in front of everything. To be clear: I do not blame the writers of the extension for this. It is a necessity given the current state of PHP.

Even in my own code, I have seen a use for this. We have had to write implementations for EDI (ANSI X12) formats. Naturally, the terminology in the files themselves is similar and I usually find myself dividing a file into header, detail, and footer sections anyway. The names would naturally conflict. Usually, the formats do not get used within the same script, so it is not apt to be a problem. They sometimes do, however, and the chance is always there for it to be needed in the future. So, I tack the name of the format to the beginning of each class name Edi999Footer, for example. Creating a package Edi999 with a class Footer would seem much more natural and would head off any potential problem very nicely. So, in short, I was looking forward to namespaces.

Then I found out what the currently selected operand is: \. Like a great many other people, I do not like this at all. While some were purportedly saying that they do not want their source files looking like Windows registry dumps, my reason is actually that the backslash is, almost universally, an escape character. I know that I will probably read

new  Package\Nubia()


new Package

while I am scanning through source files (not that these names exist; just a hypothetical). It is just wrong to use the escape character as a separator (on a tangent, it was wrong when MSDOS did it, too).

That said, I understand the snag that they had hit. They really were running out of common characters and character combinations. That is, they were if the goal was to maintain near 100% compatibility with the previous syntaxes. To select an operand that would be considered more decent, one would have to break something in the current PHP language. A friend and I tried a little thought experiment on a blackboard. I wrote up a statement like the one above, but removed the separator. Then we tried to come up with one that wouldn't break the current language. We couldn't come up with anything that was really better.Ideas like ==| and ===> were as good as they got, but those are pretty lousy.
However, the addition of classes (which I count as really happening in PHP 5; PHP 4 classes were little better than C structs) and namespaces is, itself, a break within PHP. A break from a dumbed down Perl with a very scriptish hackish feel to something that is more akin to the "professional" nature of Java or C#. In short, they are already breaking with the original spirit of PHP, so why not break a little from its syntax? I am not proposing to make PHP as strict as Java or C#. If that's the objective, we should just use Java or C#, but if the thrust of the language is going to be more for "professional" developers then why not modify the syntax accordingly?