Before PHP  went OO and autoloading existed, users had little choice but to place require_once statements throughout their code to satisfy the application dependencies.  At the start of a project this was fine as the dependencies were thoughtfully mapped out and the require_once statements strategically placed.  However, as time goes on and code goes through maintenance the require_once creep starts to set in.

What do I mean by require_once creep?  I simply mean that there are require_once statements including code that doesn't need to be included.  This caused a couple of problems:

1. More code for the PHP parser to parse and thus a slower application
2. Confusing code dependencies

Now, admittedly problem 2 is not the major issue problem 1 is.  However, nothing is more frustrating than removing a innocuous require_once from a file only to have some other random file break because it was including that file and depending on that require_once.  There is an entire PHP extension dedicated to helping people solve this very problem: inclued.  I still remember Mozilla's conference talk about refactoring TikiWiki to not simply include every nearly every single library file on every single page.

To fix this problem, autoloading was introduced.  This allowed people to stop using require_once and spawned a method of pseudo-namespacing files.  One of the more popular methods of psuedo-namespacing was the PEAR standard.  This standard said to name the class based on the directory location of the class.  So if I have class in herman/awesome/Solution.php I would name the class Herman_Awesome_Solution.  This obviously gave rise to some pretty long class names, but people generally loved it as it saved them from require_once creep.

Let's fast forward to PHP 5.3.  The "use" keyword is introduced to let users alias long namespaces to a shorter name.  So I can reference the namespace \this\is\a\really\long\namespace as longns.  This is great, now I can reference a really long namespace with a single word.  All I have to do is remember to alias it.  And the aliases are descending, so if I alias a class that alias two other classes, I can use those additional aliases free of charge.

But wait, doesn't it seem like we just went full circle with naming conventions?  We started with simple class names with require_once creep, graduated to autoloading and using super long class names and are now back using simple class names with use creep.  The use creep doesn't have the performance halting side effects of require_once, but it sure seems like it can cause quite a dependency maintenance nightmare.  It may be no problem for you, but what about the guy coding next to you who really doesn't care?

I think I will stick to using the fully qualified namespace (FQN) of a class.  It will take a few more keystrokes, but it keep my dependencies cleaner.

1. Prefix a relative url path with a host.
2. Rotate a set of relative url's through a given number of cdn hosts.

We currently use Zend Framework at work, so it is only logical we use as much of the framework as possible.  The straight forward approach is to extend Zend_View_Helper_Abstract and create a few functions to fill the requirements.  There are few problems with this approach.  The first is function creep.  We know we need to prefix http://www.hautelook.com and https://www.hautelook.com, but there may be more later.  We may decide to use something like https://ssl.hautelook.com or require another subdomain like http://ftp.hautelook.com.  This would require us to create another function, write some unit tests for it and finally send it through QA.  This issue is even more compounded with the cdn rotation function.

Another problem is that we need absolute url's in some of our business logic.  We have webservices that serve up XML or JSON that contain locations to such as images or a catalog.  We want these services to take advantage of the absolute url logic too.  If we implement a view helper, then the service layer becomes coupled to the view in order to reuse the logic.

Enter PHP 5.3, functional programming and an inspirational post from Eli White.  We can use the factory method pattern and closures to meet all the requirements and isolate the parts that change.  Read these posts if you are not familiar with functional programming in PHP.

class Crimson_Url
{
    public static function absolute($host)
    {
        return function($path) use ($host) {
            return "{$host}{$path}";
        };
    }
 
    public static function rotate($subdomain, $host, $rotations, $protocol='http')
    {
        $current = 0;
 
        return function($path) use (&$current, $subdomain, $host, $rotations, $protocol) {
            if ($current == $rotations) {
                $current = 1;
            } else {
                $current++;
            }
 
            return "{$protocol}://{$subdomain}{$current}.{$host}{$path}";
        };
    }
}

The absolute function demonstrates how simple, yet powerful, closures can be.  The absolute function is creating a function that concatenates to strings together: a host name and a relative url.  Here is how we would use this:

$www = Crimson_Url::absolute('http://www.example.com');
$ssl = Crimson_Url::absolute('https://www.example.com');
 
echo $www('/foo.jpg'), PHP_EOL;
echo $ssl('/secure.php'), PHP_EOL;

Output:

http://www.example.com/items.php

https://www.example.com/secure.php

Take this one step further and think about how you can use the HTTP_HOST or HTTP_REFERER values from $_SERVER to make absolute URL generation almost completely automatic.

The rotate function is slightly more complex.  The $current variable is being declared in the factory method and passed by reference.  We must explicitly pass this by reference otherwise PHP will pass it by value and the value of $current will be 1 everytime.  Here is how we would use the rotater:

$cdn = Crimson_Url::rotate('cdn', 'hautelook.com', 3);
$sslCdn = Crimson_Url::rotate('cdn', 'hautelook.com', 3, 'https');
 
echo $cdn('/foo.jpg'), PHP_EOL;
echo $cdn('/bar.jpg'), PHP_EOL;
echo $cdn('/baz.jpg'), PHP_EOL;
echo $cdn('/bob.jpg'), PHP_EOL;
 
echo $sslCdn('/foo.jpg'), PHP_EOL;
echo $sslCdn('/bar.jpg'), PHP_EOL;

Output:

http://cdn1.hautelook.com/foo.jpg

http://cdn2.hautelook.com/bar.jpg

http://cdn3.hautelook.com/baz.jpg

http://cdn1.hautelook.com/bob.jpg

https://cdn1.hautelook.com/foo.jpg

https://cdn2.hautelook.com/bar.jpg

Notice how there are no problems with static variable conflicts. Each function is independent and can be used for completely different tasks.

The complete source code, with tests and documentation, can be found here: http://github.com/hradtke/crimson/tree/master/Crimson_Url

One major difference between PHP and JavaScript style closures.  Here is a typical JavaScript closure:

// start counting from some number
function counter(n) {
    return function() {
        return n++;
    }
}
 
countFrom3 = counter(3);
console.log(countFrom3());
console.log(countFrom3());
console.log(countFrom3());
console.log(countFrom3());

We can write this same function in PHP.  The main difference is the "use" identifier required for closure:

<?php
function counter($n) {
    return function() use($n) {
        return $n++;
    };
}
 
$countFrom3 = counter(3);
echo $countFrom3(), PHP_EOL;
echo $countFrom3(), PHP_EOL;
echo $countFrom3(), PHP_EOL;
echo $countFrom3(), PHP_EOL;

If you run this code, it will not work as expected: every number will be 3.  Why?  Well, the closure RFC for PHP requires that variables are only explicitly passed by reference.  That means we need to use modify the function signature:

<?php
function counter($n) {
    return function() use(&$n) { // <--- note the pass by reference syntax
        return $n++;
    };
}

Now JavaScript does not have traditional classes like PHP.  Instead, we define an object with a set of variables.  Object methods are simply variables that reference an anonymous function.  Something like this:

obj = {};
obj.add = function(l, r) {
    return l + r;
};
 
console.log(obj.add(1, 2));

Let's write that same function in PHP.  It has very similar syntax:

<?php
$obj = new stdClass;
$obj->add = function($l, $r) {
    return $l + $r;
};
 
echo $obj->add(1, 2), PHP_EOL;

If you run this you will notice that PHP complains that the object does not have that method.  In PHP, functions are not quite first class citizens.  The variable function is completely ignored and only explicitly declared method's are allowed to be called this way.  We need to modify our example to make this work:

<?php
$obj = new stdClass;
$obj->add = function($l, $r) {
    return $l + $r;
};
 
$add = $obj->add;
echo $add(1, 2), PHP_EOL;

With these nuances out of the way, you have can have a productive functional hacking session.  Have fun!

All this talk of functional language features is great, but Lithium is still in development, Zend Framework 2.0 is a ways away, you have an upcoming project deadline and you want to know how this stuff can help you now.  Easy: go read or watch JavaScript examples.  Seriously.  Watching Douglas Crockford's videos on YUI theatre or reading through ExtJS source code can give you really good insight into the power of functional language features.  The syntax may be different, but the core ideas are the same.

The new functional feel of PHP seems to have started a trend towards a unified constructor.  This has been a common practice in the JavaScript community for some time.  The great thing is that the PHP array is very similar to the JavaScript object.  In fact, the JSON extension to PHP makes them completely interchangeable.  Here is a quick example of one unified constructor implementation in PHP:

<?php
 
$p = array(
    'a' => 'hi',
    'adder' => function($n) { return $n + 1; },
    'c' => 3,
    'd' => new stdClass
);
 
class base {
    function __construct(array $params)
    {
        foreach ($params as $key => $value) {
            $this->$key = $value;
        }
    }
}
 
class foo extends base { }
 
$foo = new foo($p);

I have a bunch of ideas (some great, some maybe not so great) that I plan on implementing using lambda functions and closures. I will be adding new components to my Crimson library and discussing them here.

One of the troubles with including files is that the current directory is constantly a moving target. Consider the following structure:

index.php
admin/index.php
includes/
    foo.php
    bar.php

Imagine for a moment that both index.php and admin/index.php include includes/foo.php. If foo.php includes bar.php, the relative directory is either "../" or "../admin/" depending on whether index.php or admin/index.php was executed. The use of the dirname() function along with the __FILE__ magic constant solved this problem for a long time.

The __FILE__ magic constant gives the full path and filename of the current file. The dirname() function gives the directory name of a file path. This was used prior to PHP 5.3 to solve the include problem described above.

<?php
// foo.php
require_once dirname(__FILE__) . '/bar.php';
?>

In PHP 5.3, this has been super-ceded by the use of the __DIR__ magic constant.

<?php
// foo.php
require_once __DIR__ . '/bar.php';
?>

Why the change? Well, it is more succinct and more clear on what is going on. Also, the magic constant is part of the Zend engine, so it is a little more performant as well.

$baz = new \foo\bar\Baz;

The spl_autoload() function gets passed the fully qualified namespace as well as the class name. This is very similar to the PEAR class naming convention of using underscore characters (_) to denote the path to a class.

Consider the following:

The spl_autoload() funtion is passed the string 'foo\Bar'. The extensions registered by spl_autoload_extensions() are then used in conjunction with include paths to look for a valid file. The spl_autoload_extensions() function has the extensions .inc and .php registered by default. The default include_path is the current directory, so let's assume the current directory is D:\herman\php.

List of attempts by spl_autoload() to load the class from the above example:

• D:\herman\php\foo\Bar.inc
• D:\herman\php\foo\Bar.php

This means that you can map each namespace to a directory in your application. Consider the following directory layout.

blog\
models\
Author.php
controllers\
PostController.php

The namespace for the Author class in the Author.php file should be 'blog\models'. The namespace for the PostController class in the PostController.php file should be 'blog\controllers'. Using this namespacing strategy along with a proper include path allows php to autoload your classes out of the box.

Remember, this only works with PHP on Windows.  I have a pending patch to make spl_autoload() work with namespacing by default on Linux.

For the time being I will be keeping a 5.2 and 5.3 version of the Crimson framework until PHP 5.3 becomes even more stable.