PHP Namespace Delimiter Controversy: “set sail for fail”

PHP is a popular, and often maligned scripting language, which evolved originally as a means for creating dynamic web pages. The software that runs the iSchool website, “Drupal,” is written in PHP. One of the biggest criticisms with PHP is the fact that it has thousands of built in functions, many of which share the same “namespace.” If you recall from our XML lectures, a namespace allows one to use the same element names from different XML vocabularies in the same document, as long as they are referenced in the context of their namespace. For example, two elements with the ID “name” can be used in the same XML document, if each has a unique namespace:

<book:name>Some Book Title</book:name>

<store:name>Some Store Title</store:name>

Fail BoatSome PHP function names get around this problem by having long psudeo-namespace identifiers, such as “preg_match_all” (performs a global reg/ex match). Unfortunately, there is not a lot of standardization between these names, meaning coders must deal with time-consuming inconsistencies. PHP developers recently decided that real namespaces are an important feature, but were not in agreement as to how to implement them. XML, as you know, uses the colon, “:”, to facilitate namespaces within a tag . Other languages, like Python and Java, use a dot, “.”,  to define which classes are imported from a particular package’s namespace. However, PHP developers have decided to define a namespace using the backslash, “\”, which has generated quite a bit of criticism. One major concern is that the backslash is also used as an escape code for special characters, such as “Tab” - which can also be represented as “\t.” So, will there be cases in the PHP code where a function like “MyPackage\transform” will be misread as “MyPackage[TAB]ransform?” Also, backslash is not in the same place on different keyboard layouts. Is this a choice that is biased toward certain users? One blogger has referred to the backspace choice as a decision that will cause PHP to “set sail for fail.”

Like the standardization negotiations we discussed in class, the PHP namespace implementation came about after quite a lot of discussion. However, based on the controversy, discussion probably could have used a little more time, and a few more voices before a final decision was made. Today, Slashdot had a link to the long IRC chat log where the choice was finalized, and here is a link to the pros and cons of namespace design on php.net.

2 Comments

  1. Michael Manoochehri Said,

    October 28, 2008 @ 12:16 am

    Ugh! Look at this ugly eval() statement from the IRC chat:
    eval(”$y = a\new_foo($x);”);

    Really? It can’t be:
    [17:02:45] eval(”$y = a::new_foo($x);”);
    ???

  2. Ryan Greenberg Said,

    November 9, 2008 @ 10:25 pm

    I agree that the new namespace delimiter looks ugly, but I don’t think it will affect PHP development in any meaningful way. The language is already known for its completely haphazard design; it’s not like the backslash namespace delimiter is a blight on an otherwise brilliantly designed system. It’s just another bolt holding the PHP ship together. Reading the chat transcript you do get the sense of how arbitrary the delimiter decision was. It seems like there was some technical reason that :: wasn’t an option–it might get confused with the current syntax for accessing class methods without instantiating an object (Class::my_method)–but couldn’t we work out something better?

RSS feed for comments on this post