At the PHP UK conference, I saw Sebastian Bergmann’s presentation on lambda functions, closures and traits. Lambda functions and closures are scheduled for 5.3 (or fivethree, as I’ve affectionately named the binary), or later. The presentation was intriguing, but has only simplistic examples, sufficient to illustrate the mechanical aspects. It left me curious as to what these features could be used for in real programs.

Before we start playing, let’s get the basic terminology clear. Lambda functions and closures are two fancy names for (variations on) anonymous functions. These are functions that are more flexible than ordinary functions and can be stored in variables or defined just where they are needed.

Anonymous functions are possible even in pre-5.3 PHP. They can be created using create_function(). But this is cumbersome, ugly, error-prone and possibly insecure. PHP 5.3 lets you do this in a much more natural and pleasant way.

The most basic and obvious case is sorting. Here is an example from Sebastian’s presentation:

<?php

usort(
    $list,
    function ($a, $b) {
        if ($a == $b) return 0;
        return ($a < $b) ? -1 : 1;
    }
);

In PHP before 5.3, this must be done either by using create_function() or by defining the function somewhere else, away from where it’s actually used. The above is clearly much better.

What else can we do with anonymous functions? In Ruby, they are the standard way of processing arrays. For example, if we want to process a set of files, adding a directory name at the beginning, we can do this:

files = ['pdo.a','pdo.la','pdo.so','sqlite.a','sqlite.la','sqlite.so'];
files_with_dir = files. map  { |f| "modules/#{f}" }

The snippet inside the braces is a function. map is the Ruby equivalent of PHP’s array_map(), except that Ruby is built to do this particular trick. But let’s try the equivalent with PHP 5.3. First we define the array:

$files = array('pdo.a','pdo.la','pdo.so','sqlite.a','sqlite.la','sqlite.so');

And then we process it:

$filesWithDir = array_map(
    function($f) { return "modules/$f" ; },
    $files
);

Interesting, but not necessarily better than the conventional alternative:

$filesWithDir = array();
foreach ($files as $file) {
    $filesWithDir[] = "modules/$file";
}

Using array_map() seems like a realistic option, at least for some cases. It reads differently because it’s conceptually different, focusing on processing the entire array rather than one element at a time. You might find it cleaner. And in some cases, it will be clearly superior. If you have a slightly more complex structure than a simple one-dimensional array, you can use array_map_recursive() to simplify the code dramatically.

In part 2, I’ll present an example of a JavaScript-style class composed of closures.

The analogy between cleaning and refactoring is useful for making the non-developers understand that refactoring is absolutely necessary. But beyond this pragmatic similarity, are the two really similar in deep and meaningful ways? I don’t think so. Refactoring is not unskilled labor. It’s a task that both requires and builds design skill and experience. While anyone can see that a floor is dirty, identifying code smells is non-obvious, tricky and demanding. This is true even of the simplest code smell, duplicated code. Although spotting code duplication is sometimes easy, at other times, the duplication is too subtle to be easily identifable. When you clean a floor, the goal is well-defined and easy to visualize. When refactoring, you may know what you’re aiming for at each small step, but just a few moves further ahead you may end up with a structure you hadn’t imagined.

I'm vaguely wondering if he's also understood the potential of the smooth, agile ride from the immediate to the complex. Probably not.

To quote myself from the Sitepoint PHP Application Design forum, to the question When do you think it is time to develop a custom framework?, I answered:

Never. Always. Start dirt simple and refactor to eliminate duplication. When you need a specific feature, study how it's done in existing frameworks and implement it. That will get you a “framework” that has exactly what you need.

This is an approach that is facilitated by the immediacy of PHP. Is this approach slower, long-term, than adopting a framework? That probably depends on a lot of variables. If an existing framework does everything your application
needs, it may be a great idea to use it. On the other hand, if you need to do things that are significantly different from what the framework supports, you need to start mucking about with the framework itself. In that case, it may be more
effective to have you own “framework” that fits the application like a glove, without a lot of features you will never need, and without features that are almost, but not quite what you need.

I love Ruby, but I've never actually tried Rails. Reading Rails tutorials, I'm not quite as impressed as some folks I know.

Uncle Bob (Robert C. Martin) has blogged about testing GUIs (web interfaces, that is; JSP and Rails) without having to run a web server. I don't think it answers all the challenges I'm up against currently, but it inspired me to some heavy thinking about the essential issue of complete and not too cumbersome test covrerage

My conclusion so far is that Uncle Bob's articles is an example of what we may call the paparazzi principle.

Paparazzi try get as close as possible to celebrities they prey upon. The fewer walls or windows between the camera and the victim, the better. Pictures should be as revealing as possible; naked is or half-naked is good.

The paparrazzi principle for web testing is this: run the test from “above” as close as possible to the component you want to test. Inject mock objects from “below” as close as possible to the component you want to test. Even in ordinary unit testing, this can be far from trivial. Where the web interface itself is involved, it is much harder.

It follows that you don't want to use a real web browser or web server unless you must. It also follows that a realtively simplistic web client (SimpleTest's web browser is a good example) without a user interface is preferable to a web browser for human use. Unless you absolutely need it, that is. Therefore, Selenium is probably a step in the wrong direction. I want test tools that enable me to test user interaction without having to fire up these voluminous masses of software.