kuwamoto.org

In the previous entry, I talked about some of the reasons why asynchronous programming can be hard to understand. Now, for some approaches for simplifying things.

Using closures

The first piece of the puzzle is closures. Ely Greenfield (one of the Flex architects) showed me a cool way to use closures to hide some of the complexity of argument passing.

In our last episode, we passed arguments from one part of the code to the next via the call object, like so:

public function getAlbumInfo(albumId: int) : void
{
    // Initiate the call.
    myService.request = { type: "album", albumId: albumId };
    var call : Object = myService.send();

    // Save the albumId for use later.
    call.albumId = albumId;

    // Wire up the handler.
    call.handler = getAlbumInfoResult;
}

public function getAlbumInfoResult(event: Event) : void
{
    // Deal with the results of the previous call.
    var artistId: int = event.result.album.artistId;
    myAlbumList.addAlbum(event.call.albumId, event.result.album);

    // Initiate the next call.
    myService.request = { type: "artist", artistId : artistId };
    var call = myService.send();

    // Save the artistId for use later.
    call.artistId = artistId;

    // Wire up the handler.
    call.handler = getArtistInfoResult;
}

public function getArtistInfoResult(event: Event) : void
{
    // Handle the results of the second call.
    myArtistList.addArtist(event.call.artistId, event.result.artist);
}

If you use closures to handle the argument passing, the code looks like this:

public function getAlbumInfo(albumId: int) : void
{
    var call: Object;

    // Initiate the first call.
    myService.request = { type: "album", albumId: albumId };
    call = myService.send();

    call.handler = function (event: Event) 
    {
        // Handle the results of the first call.
        var artistId: int = event.result.album.artistId;

        // Notice we can use albumId here directly.
        myAlbumList.addAlbum(albumId, event.result.album);

        // Initiate the second call.
        myService.request = { type: "artist", artistId: artistId };
        call = myService.send();

        call.handler = function (event: Event)
        {
            // Handle the results of the second call.
            myArtistList.addArtist(artistId, event.result.artist);
        }
    }
}

This is a bit tricky, so let’s walk through it.

1. myService.request is set.
2. The first request is sent.
3. The callback is stored on the call object for the http request.
4. Eventually, the result handler is called.
5. We look up the callback on the call object, and call it.
6. This causes the first closure to be called.
7. Inside the first closure, I can access the albumId parameter from the outer function, because that’s how closures work.
8. Inside of there, a second http request is made.
9. A new callback is stored on a new call object.
10. Eventually, the result handler is called.
11. We look up the callback on the call object, and call it.
12. This causes closure2 to be called.

So what’s so great about this method? Well, in Ely’s words, “if you squint, it almost looks like you’re not doing asynchronous programming.” You don’t have to register asynchronous event handlers, and you don’t have to do anything too hard to pass arguments around, because of the magic of closures.

~

First attempt at cleanup (using Deferreds)

The first thing to clean up is to formalize how the callbacks are registered. Yes, there is code somewhere in the system that calls the handler once the result comes in, but it’s just some code I wrote somewhere, and it’s not managed by a class. Furthermore, it’s not clear what happens if we want to add an additional handler, or if we want to add a callback for when the call fails.

The Twisted network engine for Python has a notion called “deferred” which is a callback handler object.

In Twisted, all asynchronous calls return an object of type “Deferred”. A Deferred is an object that, among other things, has a list of callbacks and “errbacks” which are called when an error occurs.

One of the benefits of the Deferred approach is that it makes the handling of all asynchronous operations work in a consistent way. In order to ensure consistency, you really want this to be baked into the frameowrk. I did the next best thing, which was to extend the framework myself.

In my first attempt, I created an IDeferred interface and a Deferred type. I decided to use the names “result” and “fault” instead of “callback” and “errback”. I added methods to add and remove handlers, just like in Python. I modified the send() method to return an instance of IDeferred instead of the call object. This allows you to use the following:

public function foo() : void
{
    var d : IDeferred = myService.send();
    d.addResultHandler(blah);
    d.addResultHandler(anotherHandler);
    d.addFaultHandler(blah2);
}

This works fine for result handlers that are best expressed as functions, but doesn’t work so well for the closure trick above:

public function ugly() : void
{
    var d : IDeferred = myService.send();
    d.addResultHandler(
        function(event: Event) : void
        {
            // do something
        }
    );
}

Adding setters

To make the syntax cleaner, I added setters to the mix. By creating a setter called “onResult” for the result handlers and “onFault” for the fault handlers, you can now use assignment, which is a more natural syntax for dealing with closures.

public function pretty() : void
{
    var d : IDeferred = myService.send();
    d.onResult = function(event: Event) : void
    {
        // do something
    }
    d.onFault = function(event: Event) : void
    {
        // do something else
    }
}

This operation clears out any existing result handlers and sets the result handler to be the new function. Because ActionScript 3 doesn’t have an overridable += operator, there was no natural way to express “add handler” using a similar notation.

Hiding the concept of deferred

Ideally, people shouldn’t have to know about the Deferred unless they absolutely need to (for example, if you need to pass the deferred from one function to another). One (tricky) way to hide the use of the Deferred is to chain the result of the send without storing the Deferred in a local variable.

public function tricky() : void
{
    myService.send().onResult = function(event: Event) : void
    {
        // do something
    }
}

Of course, there is no way to attach a fault handler with this approach. I ended up defining a property on my version of HTTPService that stored the most recent deferred. I called it “lastCall” which is clear in some ways and confusing in other ways. If you can think of a better name, I’d love to hear it. In any case, here is what the code now looks like:

public function lessTricky() : void
{
    myService.send();
    myService.lastCall.onResult = function(event: Event) : void
    {
        // do something
    }
    myService.lastCall.onFault = function(event: Event) : void
    {
        // do something else
    }
}

Relying on “lastCall” instead of returning a Deferred

Once I added the “lastCall” property, I ended up using this idiom the most, and backed out the change in which I had previously changed the return value of the send() method. This was partly practical and partly philosophical. In practical terms, I found that certain asynchronous methods (such as DataService.commit()) returned typed objects, which meant it was harder for me to hijack them in a subclass. In philosophical terms, I had always felt guilty about subclassing a class and hijacking the meaning of the return value.

The end result

I’ve been using this approach for a while, and it’s been working out fairly well for me. I still have a niggling concern in the back of my head if this infrastructure might just be too fancy for its own good, but for now, I find it a faster and easier way to work. Here’s a stripped down version of some code I’ve been writing recently. Having the flow of control represented inline like this makes it easier for me to understand what’s going on.

public function authenticate() : void
{
    // Show the dialog.
    var loginDialog : LoginDialog = LoginDialog.show();
    
    loginDialog.onResult = function(event: Event) : void
    {
        // If the user was a new user,
        if (loginDialog.isNewUser())
        {
            // Create an account.
            userManager.create(loginDialog.username, loginDialog.password, loginDialog.email);
            userManager.lastCall.onResult = function(event: ResultEvent) : void
            {
                // more logic here.    
            }
            
            userManager.lastCall.onFail = function(event: ResultEvent) : void
            {
                // add failure logic here.
            }
        }
        else
        {
            // Otherwise, authenticate existing account.
            userManager.authenticate(loginDialog.username, loginDialog.password);
            userManager.lastCall.onResult = function(event: ResultEvent) : void
            {
                // more logic here.    
            }

            userManager.lastCall.onFail = function(event: ResultEvent) : void
            {
                // add failure logic here.
            }
        }
    }
}