• Traits
• Class member access on instantiation: (new Foo)->bar()
• Short array syntax: ['blue', 'red']
• ext/mysql, mysqli and pdo_mysql now use mysqlnd by default
• New typehint: function( callable $callback )
• Closure::bind() and Closure::bindTo()
• Class::{"foo$bar"}()
• Method call through array: $cb = array($obj, 'method'); $cb( $args );
• Built-in web server: php -S localhost:8080
• <?= is now always available regardless of the short_open_tag setting (pure PHP templates ftw)

In addition to safe mode being removed, there’s also this:

Removed magic_quotes_gpc, magic_quotes_runtime and magic_quotes_sybase ini options. get_magic_quotes_gpc, get_magic_quotes_runtime are kept but always return false, set_magic_quotes_runtime raises an E_CORE_ERROR. (Pierrick, Pierre)

// cache the file on the filesystem
$path = tempnam('/tmp', 'foo');
$fp = fopen($path, 'w');
fwrite($fp, $sweet_data);
fclose($fp);

// file has contents; now store a read-only pointer to the file
$cache[$key] = fopen($path, 'r');
unlink($path);

The file is unlinked as the last step, removing it from /tmp, but it's still available for fseek() and fread() through the cached file pointer (in a static, singleton, or other non-persistent store of choice). When the request ends, the pointer is closed, and the filesystem will free the space used by that file.

No keeping track of files for cleanup, no registering a shutdown function, and we don't have to retain the file contents in memory.

I’m not going to stand up in a very strong defense of PHP. There is plenty wrong with it, but its popularity is due to its low barrier to entry:

• It’s ubiquitous in cheap shared hosting environments
• It’s easy to create your first script (create a .php file in the web directory)
• There are a plethora of tutorials

This attracts a pretty scary demographic: the non-programmer. Just look at the PHP questions on Stack Overflow. On any given day it’s a complete mess, a land where HTML is intermingled with PHP and everyone is using the old-school MySQL API. Separation of concerns, escaping data, MVC, OOP, and any number of other concepts are above these users, for now. They’re just trying to get something on the page in the way their language seems to encourage.

The crux, then: if your language has a high barrier to entry, you effectively lock out some portion of unskilled users. Saying you don’t want to “compete” with PHP means retaining your high barrier to entry. Is it better to attract programmers who already have some ability, or to encourage a wider installed base? Would you rather tell a newbie, “Write your app with PHP, it’s easy” or “Write your app with Python, it’s good?” I prefer the latter.

So, from now on I’ll just consider symlinks harmful, I suppose.

Passing non-arrays

Let’s first look what happens when we pass a non-array as the second argument to call_user_func_array():

function foo() {
    var_dump( func_get_args() );
    return 7;
}

var_dump( call_user_func_array( 'foo', 3 ) );

Here’s the output in PHP 5.2.17:

array(1) {
  [0]=>
  int(3)
}
int(7)

And here’s PHP 5.3.5:

PHP Warning:  call_user_func_array() expects parameter 2 to be array, integer given in /tmp/call_user_func_array.php on line 9
NULL

In my definition a “warning” wouldn’t refuse to run a specific command (the callback) and then continue with program execution, but c’est la vie. One fix is to typecast as array, which turns a scalar into a single-element array:

call_user_func_array( 'foo', (array)3 ); // array( 0 => 3 )

However, typecasting would turn an object into an array. An object with three properties would become an array with three elements, so the callback would get three arguments (the properties) rather than one argument (the object). The best solution is to check is_array():

call_user_func_array( 'foo', is_array($args) ? $args : array($args) ); // $args, or array( 0 => $args )

Passing by reference

Let’s try a callback that expects to get parameters by reference:

function foo( &$input ) {
    var_dump( $input );
    return 'goodbye';
}

$args = array( 'hello' );
var_dump( call_user_func_array( 'foo', $args ) );

The old PHP 5.2.17 behavior:

string(5) "hello"
string(7) "goodbye"

And now, in PHP 5.3.5:

PHP Warning:  Parameter 1 to foo() expected to be a reference, value given in /tmp/call_user_func_array.php on line 9
NULL

Same deal as before: things basically fall of the tracks, with the callback never executing and the function returning null. One fix is to pass $args by reference, and remove the & from the function definition:

function foo( $input ) {
    var_dump( $input );
    return 'goodbye';
}

$args = array( 'hello' );
var_dump( call_user_func_array( 'foo', &$args ) );

Or if you don’t really require pass by reference (you’re not modifying the input) just remove the & from the function definition and be done with it.

I’m assuming that most of my readers will fall into two groups: those with modest needs who are looking to build their own software and readers with more demanding needs who will be using a tool. … There is a third category; those with demanding needs who want to build their own software. The first thing I’d say here is to look carefully at using tools. I’ve seen more than one project get sucked into a long exercise at building frameworks, which wasn’t what the project was really about.

I have been acutely aware of this, lately. The specific sorts of patterns I’m looking for (e.g. active record) could be done for me, were I to use a framework. There’s a lot to weigh:

• Increased difficulty of maintenance as we complement our own set of home-grown, evolved tools with third-party tools. All the old code doesn’t just go away.
• Training new and existing developers in a specific toolset (though in theory this would offset some of our own documentation requirements)
• Finding a tool that actually fits our needs (Zend, Lithium, Doctrine, CodeIgniter, Kohana,  etc.)

My impression is that Zend would most easily fit into our existing development. We could cherry-pick components, increasing our dependence as we grow in comfort and retire old home-grown tools. Maybe the same is true for other projects. I’d love to build a simple project using each of these tools, to really get a feel for their ins and outs.

At some level, I’m just tired of writing simple SQL statements.

For me, the main appeal of a factory is one-line instantiation of classes. This allows for clean, clear dependency injection in object instantiation, but quick access to an object without a lot of duplicated code, and also has the potential to reduce overhead when creating an interface to a data store. (In my previous example, the factory method cached a reference to the database object using a static.)

But what if the factory itself were its own class?

class UserFactory {
    public static function userstore( $new_store = null ) {
        static $userstore;

        if( $new_store !== null ) {
            $userstore = $new_store;
        }

        // default userstore if one wasn't provided
        if( $userstore === null ) {
            $userstore = new UserStore_Database( DB_USER, DB_PASS );
        }

        return $userstore;
    }

    public static function load_by_id( $id ) {
        $user = new User( self::userstore() );
        $user->load( $id );

        return $user;
    }
}

$dbstore = new UserStore_Database( DB_USER, DB_PASS );
UserFactory::userstore( $dbstore );
$user = UserFactory::load_by_id( 12 );

Or maybe it’s better to have the factory as an object rather than a collection of static methods:

class UserFactory {
    public $userstore;

    public function __construct( $userstore ) {
        $this->userstore = $userstore;
    }

    public function load_by_id( $id ) {
        $user = new User( $this->userstore );
        $user->load( $id );

        return $user;
    }
}

$dbstore = new UserStore_Database( DB_USER, DB_PASS );
$uf = new UserFactory( $dbstore );
$user = $uf->load_by_id( 12 );

I’m not sure if one implementation is better than the other. The former seems testable, and it can be used in any scope without instantiation or prior setup, allowing for one-liners.

In the past I may have written a user class which was very tightly coupled with a database:

class User {
    public function __construct( $id ) {
         global $db;

         $sql = "SELECT * FROM users WHERE id = ?";
         $user = $db->get( $sql, $id );

         $this->id = $user->id;
         $this->name = $user->name;
    }
}

It’s easy to identify why this is hard to test: you need a database with predictable data beneath to have any confidence that the code is working as it should. A testable alterative would use Dependency Injection:

class User {
    public function __construct( $userstore ) {
        $this->userstore = $userstore;
    }

    public function load( $id ) {
        $userdata = $this->userstore->load( $id );

        $this->id = $userdata->id;
        $this->name = $userdata->name;
    }
}

Rather than instantiating a user with new User(12), I would instead say:

$userstore = new UserStore_Database( DB_USER, DB_PASS ); // create db interface
$user = new User( $userstore ); // create user object, connecting to db
$user->load( 12 ); // load user #12

This is way more verbose, but factories can automatic the common use cases:

class User {
    // __construct(), load(), plus:

    public static function load_by_id( $id ) {
        static $userstore = null;

        // cache the database interface
        if( $userstore === null ) {
            $userstore = new UserStore_Database( DB_USER, DB_PASS );
        }

        $user = new User( $userstore );
        $user->load( $id );

        return $user;
    }
}

Our object is testable, but day-to-day code in production can still use a one-liner:

$user = User::load_by_id( 12 );

When I write my unit tests, I can create a custom UserStore class that returns data from an array. The User::load_by_id() method is not testable, but honestly I don’t care. I want to test the core functionality of the user class, and if User works, then my factory works.

Most of the information I find is very specific to other languages (e.g. Java), recommending programming constructs that aren’t in PHP. My challenge is to apply this to PHP, and not get sidetracked by hard line stances like “never use statics” but rather understand those opinions in context of how they hurt testability.

• __callStatic()
• Circular reference garbage collection
• get_called_class()
• Closures
• DateTime::getTimestamp()
• Namespaces
• Late Static Binding
• Phar as part of the default install
• __DIR__ — no more dirname(__FILE__)!

PHP 5.3.0 was released on 23 June, 2009! A migration guide is available.

Django

Django’s documentation files are flat HTML, so the only real step is to build the docs using Sphinx. I’ll do this in ~/Sites/django-docs/ for consistency with my PHP setup, but strictly speaking you can access these docs without the overhead of a web server.

sudo easy_install sphinx
cd ~/Sites/
svn co http://code.djangoproject.com/svn/django/trunk/docs/ django-docs
cd django-docs
make html

The final step took several minutes to complete on my MacBook. Script output notes that the new documentation is stored in build/_html/. Open the index.html file in your browser. There’s no step 3!

PHP

The PHP setup is slightly more complicated since the docs themselves rely on PHP. (On the upside, this provides quick access to function reference with URLs like php.net/explode.) Luckily the process is well documented. I won’t duplicate their steps here, but I will share some tips.

Here is my Apache 2 configuration file. I saved this to /private/etc/apache2/other/php.localhost.conf where it’s automatically included by /private/etc/apache2/httpd.conf. Open up httpd.conf add the directive NameVirtualHost *.

Mac OS X 10.5 honors /etc/hosts, so appending something to the standard localhost line gives you a quick-and-easy local domain name. I used php.localhost:

127.0.0.1       localhost php.localhost

The initial takes a few minutes. I highly recommend using the suggested flags to ignore non-English language files and the documentation tarballs.

Finally, I had to disable the inclusion of httpd-manual.conf in httpd.conf, which was overriding http://php.localhost/manual/.

jQuery

Unfortunately, this results in a broken API browser for reasons unknown to me. I’ll leave it here in case others figure out where I went wrong.

This one is pretty straightforward, but requires another VirtualHost as the URLs are all relative to /. Personally I like docs.jquery.com better than the API browser, but those docs run off a MediaWiki install. First, download the docs. (These are also available as an Adobe AIR application, linked from api.jquery.com.)

First, add a new alias to /etc/hosts:

127.0.0.1       localhost php.localhost jquery.localhost

Now download the API browser using Subversion. For some reason, jquery-1.3.1.js is missing from trunk, so we’ll download that as well.

cd ~/Sites/
svn co http://jqueryjs.googlecode.com/svn/trunk/tools/jquery-api-browser/ jquery-docs
curl -o jquery-docs/lib/jquery/jquery-1.3.1.js http://ajax.googleapis.com/ajax/libs/jquery/1.3.1/jquery.min.js

A very simple Apache configuration file is needed. I created other/jquery.localhost.conf, just like I did for the PHP docs:

<VirtualHost *>
ServerName jquery.localhost
DocumentRoot /Users/adam/Sites/jquery-docs
DirectoryIndex index.php
</VirtualHost>

Restart Apache (sudo apachectl restart) and browse to http://jquery.localhost/. Docs!