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

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.