Disappointed with PHP namespace seperator decision

Haven’t blogged on PHP in awhile, so here goes…

It seems the PHP team has decided on using \ as the namespace separator.  I’m still flummoxed as to why :: or ::: wasn’t chosen.

So now we’ll have things like my\package\name but will we be able to use dynamic namespaces?  Like my\package\$name ?

I just have a strange feeling this is going to end up causing unintended or unforeseen problems (like many PHP decisions end up doing, which only get rectified years later).

So when will the natural successor to PHP arrive?  Natural successor would be something that can play well in virtual hosting environments, have basic understandabilty (/foo/bar.php means that bar.php is in the foo directory), act like glue between disparate external libraries (GD, etc.), be reasonably fast and open source?

I dunno.  Sometimes I get the feeling PHP continues to succeed more because of the relative failures of the alternatives.  :)

I'm currently working on a book for web freelancers, covering everything you need to know to get started or just get better. Want to stay updated? Sign up for my mailing list to get updates when the book is ready to be released!

Web Developer Freelancing Handbook

Be Sociable, Share!

{ 36 comments to read ... please submit one more! }

  1. FWIW, the arguments against :: and ::: didn’t seem very strong. ::: is a visual indicator that it’s a logical relation to what :: represents.

    It seems Ruby allows for namespace support with the ::, and they don’t seem to get too bothered about whether something is a class or namespace definition.

    obj = NameSpace::Example.new
    a = Namespace::Example::CONST

    If this was/is a major issue with the Zend Engine’s ability to parse things to support this, maybe those sorts of things should get fixed for PHP6, rather than trying to shoehorn in namespace support in PHP5.3 which will then tie PHP6 namespace support to the legacy issue of PHP5.

    Still would like to see some competition out there for PHP. Something that can embed inside Apache, doesn’t take 200meg to run, portable, cheap hosting support, etc.

  2. Have to agree I’m slightly disappointed.

  3. Slightly disappointed?

    I’m absolutely -beep- furious that they could have choosen something as stupid as a forward slash (/).

    It’s this sort of stupidity that is going to confuse the hell out of developers new and old; readability has just gone out of the window on this one. PHP had already used :: and developer have got used to it, so why go down another road altogether?

    Utter -beep- madness. Worse… To think that I’ll be stuck with it myself :(

  4. The argument against :: was that you couldn’t resolve the scope properly in a number of cases (if you had a namespace foo with function bar() and a class foo with a method bar() in another namespace, foo::bar() was in conflict) see http://wiki.php.net/rfc/backslashnamespaces#use_as_namespace_separator for more info. The only option for using :: as the separator was to not allow function declarations (as opposed to class declarations) to exist within a namespace

    The argument against ::: is, I believe, fairly valid. When used alongside :: its fairly difficult to see the difference at a glance. I’d really rather have legible code than the related operator any day.

  5. This issue has also made me look at alternatives to PHP again. Not an emo-way because of namespaces per-se; but I think the way we got here is a bad sign for things to come. I also get the feeling the core team has maybe lost a bit of momentum (people stepping down, slow slug to 5.3/6.0?).

    Re: shared-hosting. This was a key factor in PHP’s growth, but the movement away from shared environments into VPS removes that requirement and opens things up more to Ruby/Python. I think we’re hitting PHP’s peak and this could be a pivotal time, with PHPers slowing moving away to other stacks.

  6. Michael, if you’re serious at taking a look for an alternative, you can use mod_ruby to run ruby scripts exactly the same way that PHP scripts are used.

  7. I’m pretty sure the reason PHP is as pervasive as it is, is because it’s really easy to get started with. If your host supports it, you just plop some .php files on the server, point links to them, and you’re done.

    Anything else requires more configuration.

    Of course, this is also why there is so much very poorly written PHP code out there, the low barrier of entry.

  8. One more to add to the long standing list of “you musn’t do that, that make it less developper frindly”.

    One thing i can’t stand: using c(++) syntax and then diverging from it … pretty unproductive from my point of view.

  9. php is open source and you can patch it the way you want it
    yes you can fork it

    I think an semisolution would be an variable in php.ini

    and to be configurable
    so you can set it the way you want it

  10. A couple more points:

    We have == and === which are visually similar yet confusing to some people, but we still have them in PHP. They are related in what they do, yet indicate something slightly difference (the difference is lost on newbs initially, but they eventually get it). Harder to read occasionally, but it’s worked for years. ::: could have been the same.

    Given PHP’s rich history of aliased functionality, why ::: couldn’t have been an alternate syntax for \ is something I don’t get.

    re: Ruby – I’ve done some CLI Ruby, but not much direct Ruby web experience. From what I remember, it’s like standard Perl where you need to output the HTML headers and what not (or use libraries). There’s still nothing else designed ‘for the web’ which automatically adds Content type, text/html, lets you break in and out of HTML context, etc.

    @mariuz – forking isn’t an answer – it would simply create more incompatible stuff out there. Same with an ini-based separator. We have enough trouble with “is magic quotes on”-style INI settings when trying to write code that’ll work on multiple systems. Having ::: as simply another way baked in to the engine would have made more sense, imo,

    PHP’s too pervasive and easy to use for many tasks – it’s not in danger of losing any major market share over this. The alterntives still aren’t easily embeddable, easy to do basic stuff with nor as pervasive in the shared hosting space. But something still could some along and win the hearts/minds of a new generation of developers, leaving PHP as primarily a legacy/maintenance platform.

    re: VPS – I dunno. I don’t see too may VPS systems out there below $25/month. It’s not going to break the bank, but that’s what most shared hosting accounts used to cost, and people flocked to the cheaper $6/month accounts when they could. I’m not sure we’ll see an explosion of VPS systems being much cheaper until 1) the GPL versions of virtualization software gets better (better documentation, better admin tools) and 2) we have a switchover to IPv6 (which I’m dreading).

  11. The argument that you can’t resolve a Class::Method() and Namespace::Func() properly is kinda B.S.

    Just *choose* a way and coders will work around it. It shouldn’t validate a completely separate token.

    Why are namespaces treated different from classes?

    If you have Date::time() as a root namespace and a root static class method Date::time() …. why not just throw an error? It’s counter-intuitive to the whole idea of namespaces to allow a namespace and a class to collide!


    are both allowable and completely different methods in the recently decided implementation.

    Personally, I think it’s just to support Zend Framework which made a completely idiotic decision to make packages with the same name and at the same hierarchy level as class names. No other language would have allowed


    Either the term “Zend\Exeception” is a class, or a package, it shouldn’t be both.

    You don’t see java.lang as both a class and a package… Why PHP is catering to the worst practices of OOP is anyone’s guess. I really thought we would be done with the coddling of poor OOP in php6, but I guess I was wrong.

    Finally, why is BC the absolute *LAST* thing on anyone’s mind who makes PHP or Zend Engine decisions? Not only does \ look bad and make a divisive distinction between what is technically a “Class” and what is technically a “Namespace”, it requires everyone to recode what namespace support has been throw into PHP 5.3.0!

    So now will will have to support php versions
    and so on. Way to make another php4/5 rift just because you think programmers should be intimately familiar with the ZE concepts of namespaces and classes, instead of just saying.. they’re kinda the same, don’t worry about it, and don’t make them the same.

  12. I’m waiting for someone to register “gophp6.org” so 5 years from now everyone will be wondering why php 5.3 or 5.4 are the most widely used version of PHP. Here’s a hit: breaking BC for stupid syntax.

  13. I really think people are missing the whole point of why i say this is “bad” or “stupid” syntax.

    When you have special tokens to differentiate namespaces and classes you can have



    But, even if it’s not in the same script. Imagine trying to explain to someone learning PHP why one project chose to end the function name with :: and why other projects choose to end the function name with \

    Yes, they are different to the engine, but NOT TO THE PROGRAMMER.

    There are minor semantic differences that really don’t make a whole hill of beans to the person *calling* the function. Only to the person designing the function.

    This change forces nuances of the ZE up to your brain all the time. Now you *must* think about whether or not something is a class or a namespace, regardless of if you care.

    [hyperbolic question] If I’m forced to care so much about the internals of the ZE all the time, why not just code in C all the time then?

    I don’t really agree with the backslash as being the best choice for this new token, but I *really*really* don’t agree with the need for two different tokens in the first place.

  14. FWIW, 5.3 isn’t completely out yet, so anyone playing with any namespace support in 5.3 should know that nothing is solid (it’s listed as an ‘alpha’ release from August). But certainly the basic support for namespaces with :: separators already seemed to be in place and at least experimentally functional. If it’s taken out because this exposes some weird issues with ZE, then those should be fixed for PHP6 and namespaces *only* available in PHP6. We’re making decisions about how to move forward with large functionality changes in a new major version, but tying it to how things can be implemented in an essentially legacy system.

  15. But, even if it’s not in the same script. Imagine trying to explain to someone learning PHP why one project chose to end the function name with :: and why other projects choose to end the function name with \

    Even more to the point, try explaining that \validate is a function in the namespace Form, but that :: is a method in the Form class, and that both can exist at the same time.

  16. I think that :: should be left in with it’s collision potential, and \ only be used if you want to be explicit

    Just like == and ===. You can use == all the time, but you may find a situation in which you have an unexpected outcome. So, you go back to your code and be more explicit.. same value *and* type.

    It’s just like ns/class names. I don’t really care if the library creator made a static class method or a namespaced function, i just want Zend::Form::validate(). But, if there’s some collision, and there are two entities at that symbol table, well then I can go back and be more explicit, saying “Zend\Form\validate” … I actually want the namespace, not the class method.

    But, the entire purpose of namespaces is to avoid collisions. If people use them *properly*, we won’t have any NS Foo colliding with global class Foo. Why? Probably because class Foo will already be in an NS of its own.

    It seems like PHP is saying “the only way to avoid a potential collision is to make all actual code confusing.”

    Still, I would *love* to see 1 real world example of a collision between a class and a namespace. Not just Foo this and Bar that.

  17. One more reason for me to stay the Perl + Catalyst route.


  18. Relative failures of the alternatives ??
    I don’t think Ruby nor Python are failures for the web development. In fact, they’re really more powerful than PHP and they don’t make such stupid decisions as the \.

  19. @damien

    ‘failure’ with respect to adoption/hosting/etc.

    Ruby only took off in the web space *at all* because of Rails – some 10 years after the language had been around. And straight Ruby (and Python) both still seem to be like Perl, in that you have to set headers and junk when trying to write web stuff.

    In PHP, anything that’s not inside < ? ?> delimiters is assumed to be HTML for a browser. In other languages, everything is assumed to be code and non-code causes errors.

    PHP, for all its flaws, really was built with the web in mind, which few other languages can claim. Certainly none of the major languages in play today (perhaps with the exception of ColdFusion) were really designed/built specifically *for* a web environment.

  20. ~ is the best.


  21. http://wiki.php.net/rfc/backslashnamespaces#use_as_namespace_separator


    to PHP:


  22. And this is (one of) the many reasons PHP sucks:

    Attribute/Method access: foo.bar
    Static method access: Foo.bar
    Package access: foo.bar.baz

    Attribute/Method access: foo.bar
    Static method access: Foo.bar
    Namespace access: foo.bar.baz

    Attribute/Method access: foo.bar
    Static method access: Foo.bar
    Module access: foo.bar.baz

    Attribute/Method access: $foo->bar
    Static method access: Foo::bar
    Namespace access: foo\bar\baz

  23. Fuck you for using the \ !!!!!!!!!!

  24. I read through all the comments and i agree with this one the most:

    Fuck you for using the \ !!!!!!!!!!

    \Foo\Bar just looks like a stupid fuck in the woods.

    :: confusing with :::? AT LEAST ::: IS NOT AN ESCAPE OPERATOR!

  25. I’m not surprised. This seems to me to be typical for PHP.

    @Gorgonzo Olgomaria Rothschild

  26. It shouldn’t be \
    It should be %$#
    For instance:


    The namespace consists of “Framework”, “Database” and “Table”, while the class is “Exception”.

    What do you think? Isn’t %$# much better?

  27. Not at all Garfield. Not sure if that was intended to be funny or not, but it’s not. And no, %$# isn’t better at all. / or . would be better.

  28. @mgkimsal

    Of course it was meant to be funny. Jebus Christ.

  29. At first when I read this post, my response was “oh, come on — it’s a single character!” but, reading through the comments, I have to say I completely agree. As a consumer of a library, you should not need particular knowledge of the semantics used to build it.

    What I would honestly love to see (but never will) is PHP admit they screwed up making . the character for string concatenation, switch it to + and then go about using . for what all the other languages do. no more -> , :: , \ bs just .

  30. What I think is the php team is actually looking for ease of parsing on the php code.

    If they use the same operator for different things it would be harder to parse the code, while using different operators for each task facilitates it.

    It would be easy to write a code completion library and other parse tools.

  31. yes, horrible decision. I was looking for namespaces and saw this. yuck.
    syntax is something which is very crucial. when all other languages use “::”, why “\”

{ 5 Pingbacks/Trackbacks }

  1. Finally namespaces
  1. Controversed namespace separator for PHP namespaces
  1. vivanno.com::aggregator » Archive » Le séparateur d’espace de noms PHP sera le slash
  1. Retad PHP trivs ändå » Artopod
  1. Python as a PHP replacement? - Curia

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>