Closures in ActionScript

Closure are one of the cornerstones of dynamic languages, and  most of the language features like OO or frameworks are using them as a foundation. At the same time, a formal definition of closures does not really help to understand them. Let us go through few examples. First, we’ll show what closures look like, and then we’ll give you their use patterns.

It all starts with the use of an anonymous function that has access to outer lexically scoped variables:

<?xml version=”1.0″?>
<mx:Application xmlns:mx=”http://www.adobe.com/2006/mxml
   layout=”vertical” creationComplete=”doInit(event)”>
<mx:Script>
import mx.controls.Alert;
private var greeting:String=”Hello”;
private function doInit(evt:Event) : void {
  btn.addEventListener(“click”, function(evt:Event):void {
  Alert.show( greeting + “, ” + txt.text);
 });
}
</mx:Script>
<mx:Button id=”btn” label=”closure” />
<mx:TextInput id=”txt”/>
</mx:Application>

Compile and run this code. Here’s an oversimplified three-part description of closures:
Closures are functions defined in one class or function context and passed to another object for execution at a latter time.
Closure’s “attachment” happens at run-time ( and can be executed multiple times during application run) and is just the stack-frame allocation where all the context variables (“greeting” in our case) are being saved for later use. In most cases it is surrounding variables of the hosting function and current run-time class instance.
Finally, the closure execution can happen at any time, and can also have parameters at the time of call. A standard convention is to have an “Event” object being passed in with the information from the calling object.

It seems you can use closures to “snapshot” any number of parameters. Unfortunately, it is true for some dynamic languages, but not for ECMA Script ones – ActionScript and JavaScript. Let us illustrate the difference with few examples. First, let us make sure that ActionScript closures are compile-time artifacts rather then true dynamic interpreted counterparts. First, let us swap the order of closure and greetings definition statements.

<?xml version=”1.0″?>
<mx:Application xmlns:mx=”http://www.adobe.com/2006/mxml
   layout=”vertical” creationComplete=”doInit(event)”>
<mx:Script>
import mx.controls.Alert;
private var myClosure :Function = function(evt:Event) {
  Alert.show( greeting + “, ” + txt.text);
 }
private function doInit(evt:Event) : void {
  btn.addEventListener(“click”, myClosure);
}
private var greeting:String=”Hello”;
</mx:Script>
<mx:Button id=”btn” label=”closure”/>
<mx:TextInput id=”txt”/>
</mx:Application>

It still works, even though “greeting” should have been undefined at the time of closure definition – proving that just reference is being used. Also, unlike in Java, the scope of an object is the stack-frame content of the enclosing function or a class. Here is example that would not compile in Java, but is perfectly legal in AS3:

private function aaa():void{
    { var a = 1; } //in Java a is not visible outside of the block
    Alert.show(a);
}
 Flash is a stack machine, a closure is a stack variable in the enclosing function, and this stack-frame approach greatly simplifies implementation of closures and code optimizers based on stack, even though requires some adjustments in the coding style. Another issue is that we do not have object values here – everything is done by reference. Let us replace greeting’s value right before the call:

<mx:Button label=”closure” click=”greeting=’good morning’”/>

As you can see, the greeting was replaced on alert screen with the new value – would not happen if “closure” would use greeting reference by value in the time of definition.

Closures is a primary feature of ActionScript. Every method in your class is a closure. That is how it knows instance variables of the class. Essentially every class is a big closure. You can write a function with closures inside that would be very much a class for all practical purposes.

Closures are unavoidable when you use asynchronous operations or need to process an event on the other object. Almost any non-trivial action in Flex – communication with the server or getting an input from user – is asynchronous. Using closure automatically gives you the reference to the class instance in which you have your function to the external object processing the event. That is sufficient for processing the asynchronous method’s results in most cases. Automatic pointing of “this” context to the instance defining the function greatly simplifies the coding as it is natural to the developer.

Prior to Flex 2, in Flex 1.5 developers were responsible for supplying context to the closure. Ability to replace closure context gives greater flexibility to the code making it truly dynamic.

The next code samples shows a closure on an arbitrary object to provide a custom context object:

public class Closure extends Object {
   public static function create(context:Object, func:Function, … pms):Function {
   var f:Function = function():*
   {
    var target:*  = arguments.callee.target;
    var func:*    = arguments.callee.func;
    var params:*  = arguments.callee.params;

    var len:Number = arguments.length;
    var args:Array = new Array(len);
    for(var i:Number=0; i < len; i++)
     args[i] = arguments[i];

    args["push"].apply(args, params);
    return func.apply(target, args);
   };

   var _f:Object = f;
   _f.target  = context;
   _f.func    = func;
   _f.params  = pms;
   return f;
  }
 }

The following code illustrates how to call this closure:

<?xml version=”1.0″ encoding=”utf-8″?>
<mx:Application xmlns:mx=”http://www.adobe.com/2006/mxml” layout=”absolute” creationComplete=”onCreationComplete(event)”>
<mx:Script>
 <![CDATA[
  import mx.controls.Alert;
  private var myClosure:Function ;
  private function onCreationComplete (evt:Event):void {
   myClosure = Closure.create({greeting:"Good evening"},function(name:String):void {
    Alert.show( this.greeting + ", " + name);
     },"world");
   var greeting:String;
   greeting ="Hello";
  }
 ]]>
</mx:Script>
<mx:Button id=”btn” label=”closure” click=”myClosure()”/>
</mx:Application>

Now, the alert shows “Good evening, world” because the method has been applied using different context. Often this methodology is called “delegation” and used by business frameworks to centralize processing of certain events.

The above example illustrates the relationship between context, functions and closures. Using this technique allows you to implement dynamic inheritance, polymorphism  and other OO concepts.

3 thoughts on “Closures in ActionScript

  1. Closures were fun in AS1, and life savers when doing AS2 projects under a tight deadline.

    AS3? … see AS2. To me, they are hacks to get stuff done. Otherwise, they should not be used as they make code un-readble. While I understand their usage (although, not their memory ramifications), to me they have a single use case. Like __resovle, Function.apply, or the dynamic keyword, their use cases are extremely unique, but important enought to be nice to haves in the language implementation.

    Regardless, I feel like all these Java devs are “discovering” the joy loosely typed languages, just as I start to appreciate what strong-typing can really bring to a large project.

  2. Ok, so before I get verbally bashed, yes, I know you can strongly-type a closure, both as the function it is, as well as it’s parameters and contents. However, that’s just making an optimized code-mess.

  3. Jesse,
    I agree that closures have to be used very selectively. Incidently, yesterday I was explaining functions and closures to developers with “mix” of skills. It was very interesting to see that developers have been using closures in strongly typed environment to solve the problems of language limitations for 15 years without knowing it (thanks to the alternative syntaxes provided by older languages). And closures can solve multiple inheritance and API consistency issues much better then religious implementation of interfaces (a la mixins, with better syntax support from the language).
    As far as large applications – strong typing is both blessing and problem – compile time, size and retesting of monolitic applications are just few items you do not want to take majority of your time. We design our applications “for a change” (literaly) and dynamic techniques come very handy. Here is an example that has been published with the book/articles that illustrates the point:
    http://samples.faratasystems.com/AdvancedDataGrid/PropertyBagDemo.html
    itemRenderer for the grid on the left is ClassFactory – essentially newInstance function returning classes. it is overridable, extensible and can be applied to the enterprise dictionary that would contain resources like standardized properties for UI elements shown. In dynamic environment usage of the classes functions and factories becomes a murky data driven business.

    Sincerely,
    Anatole

Comments are closed.