I think one of the handiest new features in ActionScript 3 is the Dictionary object, which lives in the flash.utils package. It is a new object type that allows you to associate a value with an object key. This is similar to how array associates values with numeric indexes, and how you can use a generic object to associate a value with a string key. 

// Arrays use numeric indexes:
var arr:Array = new Array();
arr[0] = "value";

// Generic objects use string indexes:
var obj:Object = new Object();
obj["key"] = "value";

// Dictionary uses object keys:
var dict:Dictionary = new Dictionary();
dict[myObj] = "value";
It's important to understand that Dictionary uses strict equality to match the object, not the reference, as the key. This means that different references to the same object will act as the same key: 
import flash.utils.Dictionary;

var a:Object = new Object();
var b:Object = a; // reference to the same object

var dict:Dictionary = new Dictionary();
dict[a] = "fun!";
trace(dict[b]); // traces 'fun!' because a===b
You can use any type of object as a key, not just generic objects (you could use a Sprite, or an Array, for example). This includes primitives (string, boolean, number, int, uint) which are matched based on value (again, strict equality): 
var dict:Dictionary = new Dictionary();
dict["string"] = "joy!";
trace(dict["string"]); // traces "joy" because "string"==="string"
Dictionary objects are enumerable with "for in", and "for each" loops: 
for (var key:Object in dict) {
   // iterates through each object key
}
for each (var value:Object in dict) {
   // iterates through each value
}
You can also set a Dictionary to use weak references as keys. This is pretty cool, because it means that if you clear all references to an object except those in a weakly referenced dictionary, that object will be available for garbage collection, which in turn will release the reference to its value. 
var a:Sprite = new Sprite();
// create a weakly referenced dictionary by passing true as first param:
var dict:Dictionary = new Dictionary(true);
dict[a] = new Object();
a = null; // clear original reference to the Sprite.
In the above example, the Sprite is now available for collection, which in turn will free the Object for collection. This can be a very handy tool for creating memory management tools, and anywhere that you want to keep lists of objects but not interfere with their collection.

Dictionary objects can be really handy for maintaining object lists / queues, such as a doLater queue for functions (though please note the bug mentioned below), a listeners list for a custom event system, a list of Sprites in a game, or a list of row-renderers in a list component. You could cross-reference an array and a dictionary for quick look-ups in ordered lists (ex. a depth manager) - the array would hold references to objects in the appropriate order, and the dictionary would hold array indexes keyed to the objects themselves.

It can also be used for associating meta data with sealed objects. For instance, a layout manager might need to store extra data about the components it is managing, so instead of injecting that data into the component arbitrarily (which won't work in AS3 anyway), it can maintain a Dictionary that uses weak references to the components as keys, and stores the extra data as the values. This opens the door to a lot of interesting new options from a code architecture perspective.

Note that there is a known bug with Dictionary that prevents it from operating correctly with references to methods. It seems that Dictionary does not resolve the method reference properly, and uses the closure object (ie. the "behind the scenes" object that facilitates method closure by maintaining a reference back to the method and its scope) instead of the function as the key. This causes two problems: the reference is immediately available for collection in a weak Dictionary (because while the method is still referenced, the closure object is not), and it can create duplicate entries if you add the same method twice. This can cause some big problems for things like doLater queues.

I'll be discussing more about how you can use Dictionary objects with weak references in my next article on resource management.