That's it, I've had it with the bumbling idiocy of the people making syntax decisions. How the hell is a backslash easier to type and less typo-prone? The :: notation is good, I don't have to move any of my fingers all the way over to the edge, and it takes me a split-second to type it.
The points system that was used to determine the rating for each separator proposal is complete rubbish as well, 'number of chars' should not be an issue, especially if both of the characters are the same. The backslash should lose a point for typo-invulnerability.
I'm also not impressed with their argument against the :: operator, which can be found here. Why on Earth would you even allow a namespace and a class to have the same name?
I remember reading a while back about how the designers thought named parameters would overcomplicate PHP. They don't think anonymous functions or messing with namespaces and classes with the same names could lead to too much complexity and messy code, but named arguments do.
I guess something like $username = CharField(maxlength=>25, minlength=>5) is just too mind-boggingly simple and readable.

Advantages \this\is\used for paths on Windows and is intuitively familiar to those developers. According to a php|arch survey (as relayed by Steph Fox), most of their readers develop on Windows and deploy on Unix, which would imply that \these\paths are familiar

kindof. it could better mimic your path in unix. you could have 4chan/b or 4chan/s but prolly not 4chan/b/... (the three dots explicitly as a sub-namespace). the problem is that anything between two slashes is going to parse like a regex ( //.*// ).

a bigger problem with backslashes tho is it makes it harder to quote/escape. :: doesn't need to be escaped, for example. neither does ☺. or _. i dunno. the whole situation makes me think of austin powers - "who throws a shoe these days? honestly!?". everyone uses dot notation for namespaces, PHP. get over it. make it happen. you can do it!

More importantly, as stated before, the backslash is the standard escape character! We don’t need any ambiguity of the backslash, MS paths are bad enough already: “C:\\Windows\\System32\\” and all that. (I had to actually type 4 backslashes each time, in order to get the double backslash, because it’s Markdown’s escape character!)

Why on Earth would you even allow a namespace and a class to have the same name?

Actually, of all their insane arguments, that one makes sense. Otherwise, someone would write this library

namespace Foo;
class MyLocalStuff { ... }
MyLocalStuff::gooptedoo();

... and the user could break it by defining a top-level namespace called "MyLocalStuff".

Of course, this only fails if we assume that they aren't implementing a proper module system, but rather just hacking hierarchical naming support into the current mess they already have. Which, given what we've seen of PHP this far, seems like a safe bet.

Why on Earth would you even allow a namespace and a class to have the same name?

Why Earth would you even allow a class and another class to have the same name?

The whole point of having namespaces is to handle naming collisions. If you could magically prevent people from not choosing the same names for two different things, you wouldn't need it in the first place.

I've been lamenting the lack of named arguments in PHP (I often cheat and use FunctionName(array('arg1' => 1, 'arg2' => 2))). The fact that Python supports them is almost enough to make me want to jump ship.

Why on Earth would you even allow a namespace and a class to have the same name?

Because, it's currently common practice. For example, consider a hypothetical Services_Reddit package. At the moment, such a package would have a class called Services_Reddit (the nominal namespace conflicts with the class).

Need another reason? Because most OOP PHP projects use autoloading extensively, the error triggered by a conflict in class name and namespace would be almost always happen at runtime. Which is certainly not a Good Thing.

Other environments use "." and "/" (even ">" on Multics), as far as I know it is only in MS DOS where this weird "\" appear as a namespace separator, as the title indicate it is an escape character. Is the PHP people under DOSage of some mind twisting drug or do they just want to do anything to make PHP appear as obscure as possible.

As a computer scientist I consider PHP to be a weird mess of stuff. I have written a few things in PHP but I don't like it.

I agree. I've dealt with a lot of incredible fucking stupidity from the PHP camp over the years, but this is just shameful. The arguments they make in the article are so baseless and dumb that it makes me really question the people that are steering the ship.

I personally tend to think of php as a social experiment and I'd suspect php creators to be psychologists in disguise. I'm pretty sure somebody of them is writing his PhD thesis on tolerance of developers towards "questionable" design decisions & how far you can push it. In this respect, I'm quite interested in their plans for php7. Please keep us updated.

This PHP sucks. Someone ought to make a nice simple web language, something that can be interspersed into HTML pages, an interpreter that can run in-process in Apache, with a simple flat name-space and no highfalutin' stuff like objects, but plenty of hard-wired functions suited to small web sites. Sorta Perl-like syntax, people know Perl.

We'll give it true object-oriented functionality. We'll provide a means of mixing in functionality via modules, have real namespaces, and imbue it with powerful introspection capabilities. Every Christmas, we'll give the developer community a meaningful, stable release.

Right, but the PHP guys are concerned about namespaces and classes at the same level being confused with one another. e.g.

class Foo {}
namespace Foo {}

Python won't help you here, where a name is just a way to identify an arbitrary value -- conflicts of this type will result in the name being overwritten. But the likelihood of that actually happening in practice? Pretty slim, in my experience. Not to say it would never happen.

Anyway, the silly thing is that the whole reason namespaces are considered a good idea is to avoid conflicts like this. The PHP folks added namespaces to avoid naming conflicts, and then got worried about what to do if namespace names and class names conflict at any given level. Rather than going to the effort of changing name resolution logic or something clean like that, they've instead added this garbage syntax which we'll likely be stuck with for some time to come.

I don't mess with PHP all that often any more, so I don't really care. But some small part of me hoped they were headed in a sane direction beginning with 5.x.

I thought that the majority of the people who took part in that discussion* were in favour of :: anyway!

Surely you mean ::: (three colons, not two): :: is already the operator for class methods access, and the PHP parser is such a clusterfuck that you can't use the same operator to mean different things in different contexts.

Apparantly, : was not possible to use since it would conflict with goto-labels (at 17:10:46 in IRC).

Wouldn't a program which parses code be "context-aware" in some way? In the program languages I use a specific character may mean a different thing depending on how and where it's used. Surely PHP's parser must also be this?

No. Their parser is completely ad hoc and horrible, it is unable to use its context, which is why -> is used for instance member access (. is the concatenation operator so it couldn't be used) and :: is the static method operator (: was used for goto labels and of course . and -> were out due to the reasons above).

Just wait. They're unwittingly evolving towards APL. Admittedly a retarded APL with no concept of parsing scope and a standard lib which seems to have been generated using some kind of random method generator, along with countless other flaws, but it'll get there.

Calling the function b in the namespace a? Or is a: a label for a goto? You could search for all goto's, and see if any went to a, but that doesn't protect you against typos. Furthermore if there is an "a" namespace, where do you report the error? at goto a, or at a:b(); when you have no global function named b? Or what if there is both a a:b function and a global b function. Is a a label in this case or not?

Why don't they just generalize namespaces to being static classes? I haven't coded much PHP 5.0, but isn't it possible to declare classes inside classes? If the class is static, you would have a module/namespace/whatever-you-might-call-it.

Ahaha this is rich! Apparently the traditional / and . weren't "good" enough for PHP.

Please PHP, implement some more "advanced" features (like arrays. does PHP have those yet, or are they still unordered maps?) and bungle them like so. I know your language is one big joke, but apparently you've really got to turn the screws in order for people to get it.

Well no, you must remember that PHP doesn't have anything even remotely close to a (formal) grammar. Since . is already the concatenation operator and / is the division operator, their shitty ad-hoc parser wouldn't be able to disambiguate between the uses.

That's also the reason why the colon-based operator would have been ::: (yes, three colons in a row): :: is already used for classmethods/staticmethods, so it couldn't have been used for namespaces.

Something can be a broken, braindead can of worms and still be used to make things. Likewise just because something is used to make things doesn't mean we can't ridicule it. Shell scripts are still widely used even though their semantics were cast before things like lexical scoping were standard. Though with decisions like this, it doesn't seem like PHP wants to improve.

The . operator is already the concatenation operator. That pretty much ruins it for other syntax, since anything can be converted to a string and concatenated.

Edit: Also, having read the rest of your comment: Merging the concepts of vector and associative array seems like a win, to me. It was a little weird at first (I'm from the Python world, see), but now I like it.

I'd say concatenation should perhaps be '+', but we're retrofitting a language here, not designing a new one.

It seems like their fundamental mistake is making a distinction between classes and namespaces. A class/object is a namespace. (And then of course putting a bunch of straw men in their comparison table. If your parser is such that you need 37 different operator tokens, why are you proposing to make parenthesis whitespace-sensitive?)

Merging vector and map is a win. Doing so in a way that doesn't preserve the iterating order on the vector is not. I saw an example of this horrible behavior a while ago - no idea if they've fixed it since.

I'd say concatenation should perhaps be '+', but we're retrofitting a language here, not designing a new one.

PHP borrows the idea of operator-specific dynamic type coercions from Perl (not that Perl originated the idea, but it came to PHP from Perl). If the concatenation operator and the addition operator were the same, PHP would either need to give up dynamic type coercion or suffer horrible ambiguity at runtime.

The . operator is already the concatenation operator. That pretty much ruins it for other syntax

It ruins it as a single token. But what about tokens that begin with "."? For example, what about ".."? It's not like you (presumably) are going to be asking for a concatenation when you've just finished asking for one and haven't supplied the (second) infix operand.

Granted, ".." might already be in use for ranges or something (since it does that in Perl, and PHP has borrowed from Perl a lot).

As long as I'm throwing out silly ideas, it seems like "$" might have been possible. I know it's used at the beginning of variables, but this is a namespace separator, so as long as it's possible to tell whether you're within a name or at the beginning of one.

I agree that they could have used either of those with no parsing problem. As someone who has to use PHP at the job, I would be kinda upset if they reused '$' in this way (due to visual confusion when glancing over code). I've gotten used to a lot of other stuff, though. :)

(I'm going to call their namespaces 'packages' below, so I can use the term 'namespace' in the wider sense of variable namespace, function namespace, etc. (meta comment: haha that was an explicit import/rename))

The solution to dealing with clashing names is not to create two separate namespaces (packages and classes), but to not use the same name in the first place. Presumably, the 'one' package knows about the 'one::step' package (that's the point of a hierarchy), so it shouldn't be defining a class also called 'step'.

For dealing with partial names versus fully qualified names, either require all imports be explicit with error on conflict, or have the inner (local) bindings shadow the outer ones. If the author wants to reference a shadowed package, they either need to name the class something else, or use an explicit renaming import.

Well, a namespace separator never appears at the beginning of a statement. By definition, it's separating parts of a namespace, so the previous part of the namespace is the previous token, and you are not at the beginning of a statement.

The "already used" argument doesn't by itself work. If it did, then you wouldn't be able to put "@" into a quoted string. But the quotes change the context enough to make it unambiguous, so you're good.

They were talking about requiring the separator as a prefix for functions and classes in the global namespace, which would be problematic for @.

because \ is a single keystroke, it is possible to require \ prefix for all global functions/classes/constants, and conversion is minimally effortful (from personal experience trying to convert files to several namespace separators to see what it was like)

Seriously. WTF. In my mind, the backslash is pretty much for escaping. That's its singular function in my mind. It's just... not friendly on the eyes.

This is what happens when you don't focus on programmer happiness (Ruby) or human readability (Python), and instead focus on petty criteria (type-ability, typo-vulnerability, parse-ability, IDE compatibility, number of chars - really? you have so little faith in your developers that you can't overcome these?). You get ugly\ass\language\decisions.