This is a pretty common use case and I am sure most people would write the logic something like this:

There is nothing logically wrong with this code. It is a very readable and easy to understand way to write it. With the rise in popularity of JavaScript and other functional languages, some of us may take a different approach. Using the underscore framework (available for both PHP and JavaScript), you could also write it like this:

The use of a callback function should be familiar to anyone with at least a basic knowledge of JavaScript. The callback function is evaluating each item in the iterator to true or false. The major drawback to both of the code snippets is that the logic for determining whether or not an item is sold out is not able to be re-used. The use of procedural code in the first example and the use of an anonymous function in the second example also make it hard to test. We can improve the second example by not using an anonymous callback:

Now I can re-use this function and easily test it. We can use SPL FilterIterator in a very similar way to the functional example:

Now my logic for what constitutes a soldout item is isolated in a class. This coincides with the object oriented principle of "encapsulate what varies". I think the biggest stumbling block for using SPL is that it just seems too heavy. You might be wondering why you should go to the trouble of creating a new class to perform such a simple task. The procedural example above is faster to write. Some of us might be tempted to use the functional example with an anonymous function because it feels more "expressive". Now consider what happens when the ecommerce system introduces returns. The new formula for determining a soldout item is now:


availability = (purchased - sold) + returned


This isn't some hypothetical example, it actually happened. It was real easy to update the logic to handle returns and make sure the tests passed.

The last decision you have to make is whether or not to put the logic in a database query. If there is a huge performance boost by writing the logic into the query, it may be worthwhile. A query is still testable, but you have to setup some test data in the database in order to test it (which means you probably won't do write the test for it). It is harder to re-use queries, so the business logic for determining sold out items may be duplicated over a number of queries too. You also might want to consider what happens if you decide to alleviate the database load by putting the list of items for sale in a cache (like APC or memcache).

The SPL classes, especially FilterIterator, really start to shine when dealing with a dataset outside of our control. More and more platforms are becoming service based and we have no control over how the data comes back. Especially when you consider something like the Twitter API timeline response and trying to filter out any tweet that starts with "RT".

The Standard PHP Library (SPL) has quite a few exception classes that are useful right out of the box.  Additionally, these exceptions can be extended just like the Exception and ErrorException classes.

My favorite is the InvalidArgumentException.  I use this exception if some parameter to a function or method is not what I expected.

<?php
 
function doubleMe($number)
{
    if (!is_numeric($number)) {
        throw new InvalidArgumentException(
            'Unable to double a non-numeric value');
    }
}

If you are using the __call() magic method, the BadMethodCallException is another great built-in exception to use.

class Foo
{
    public function __call($name, $params)
    {
        if (!method_exists($this, $name)) {
            throw new BadMethodCallException(
                "Method $name does not exist");
        }
    }
}

The SPL exception classes are a great alternative to writing your own exceptions classes. For some more examples you can check out PHPUnit. Sebastian Bergmann uses a lot of SPL exceptions in his code there.

$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.