Log <-

PHP Namespaces committed

Gravitronic lets us know that a patch that implements namespaces in PHP has now been committed.

The last time I took a look at the roadmap for PHP6, it was still undecided if namespaces would make the cut. Seems like they have now (although they could still revert the commit, like they did with namespaces in PHP5 if I recall correctly).

The main idea of the proposal is to attack one target and this target only – the Super_Long_Really_Annoying_Enormous_Class_Names that lately became the bane of big project developer. All other things are considered secondary to this goal – no attempt to make some different include model, packaging model, etc.
Namespaces – can we keep it simple?

Some examples of how it currently works:

Defining namespaces

<?php 
namespace Zend::DB;
 
class Connection {
}
 
function connect() {
}

Referring by full namespace name

<?php
require 'Zend/Db/Connection.php';
$x = new Zend::DB::Connection;
Zend::DB::connect();
?>

Importing

<?php 
require 'Zend/Db/Connection.php';
import Zend::DB;
import Zend::DB::Connection as DbConnection;
$x = new Zend::DB::Connection();
$y = new DB::connection();
$z = new DbConnection();
DB::connect();
?>

Though I can't quite put my finger on it, it somehow still seems like a bolt-on to me. Ah well, better than nothing, right?

2 Responses to “PHP Namespaces committed”

  1. mvanbaak Says:

    It's becoming more and more like python and/or java.
    I've not made up my mind whether this is good or bad though. I think I'll wait until I can grab an rc for php6 to test stuff myself.

  2. admin Says:

    Personally, I'm happy with namespaces in PHP. It's one of the things I was missing in PHP. The absence of namespaces is/was a huge pain in the ass for a lot of projects, especially PEAR. IIRC, the PHP community/developers have long been opposed to namespaces because "you can just prepend function/classnames with a unique identifier". In the case of PEAR though, this resulted in rediculously long classnames which had to be repeated over and over and over again in your code. This isn't a huge problem if you're only doing a single DB connect call once in your source code, but it gets old really quick when dealing with static methods.

    Anyway, even though PHP is heading in the right direction, there are still things wrong with it that I just can't get over. The shoddy API is one of them. Right now, the PHP library is basically divided in regular C-like libs (mysql_connect(), etc) and OO libs (DBO, etc). Also, many of the function parameters' in the lib are not very straightforward and intuitive. This is something that's going to be very hard to change. One solution would be to make a big non-backwards-compatible release where everything's Objectified and cleaned up. But this will break PHP again like what happened during the v4 to v5 transition. All in all, I don't believe PHP can easily be 'saved' for the future. This is probably the reason why Ruby On Rails has gotten so big. I'm currently leaning more towards webdevelopment in Python (which is real bliss, compared to PHP. At least, if you're into Python) and I have to wonder how much more things I'll develop in PHP. Only time will tell.

Leave a Reply

You must be logged in to post a comment.