As David pointed out, the fact that I’m an Adobe employee and am participating in the project doesn’t mean it’s now an official Adobe product (for good or bad). I’m doing this 100% on my own time. And my role is still pretty small — David is certainly the lead, main, primary, controlling, etc. author. I just file bugs as I find them, add some comments about feature requests, and fix issues when I know how to.

In case you’re curious, the back story is really pretty straightforward. I started writing my own version of an AIR SQLite admin tool back before AIR beta 1, but never had time to take it beyond a “query runner” tool. Late in 2008 I discovered Lita, and once I started using it I realized that 1) it is implemented in a similar way to many of the ideas I had, and 2) It’s already got a big head start in features, so there’s not much point in me trying to “compete” or anything like that, especially for something that I wasn’t planning to make money from.

After using it for a while I discovered a few bugs, and decided to email David about them. (He and I had communicated a bit previously, about the encrypted database functionality added in Adobe AIR 1.5 and how to integrate it into Lita.) I think I probably mentioned in that message that I would be willing/interested to fix issues myself as I have time. Fortunately David was very kind and accepted my offer. So, as I said, now when I find issues I get to fix them myself, which is nice because I can fix them quickly, but also adds some responsibility since now the burden is on me to make those changes myself =)

As a side note, I really want to point out that David is a really great developer — something I appreciate greatly as we work in the same codebase. It is a big testament to his architectural and coding skills that I was able to dive right in and fix four bugs/feature requests in a very short time (literally a matter of minutes after first looking at the code). I’ve learned a lot just from seeing his code, and now I’m anxious to read his “Flex Architecture Fundamentals” series to learn more about the thinking behind the great code.

Having been down this road before with other languages, I decided to put together a simple tool for testing out regular expressions. I wanted to be able to enter a pattern and a test string, and have it check to see if it was a match. That way, I could test out various possible good matches (and non-matches) to see if they give the right result. I was using named capturing groups quite a bit on this project, so I added an extra feature where it shows all the groups that are captured as well.

Anyway, I realized this might be useful for anyone who’s trying to use regular expressions in an ActionScript 3.0 project, so I thought I’d make it available.

Want to test it out? Visit the project page to see the tool and download the source code.

If you have comments or improvements for the project, feel free to add a note in the comments on the project page.

• Tamarin project page
• Mozilla foundation press release
• Nice executive summary and analysis by Frank Hecker, executive director of the Mozilla Foundation
• Benchmark comparisons of Tamarin versus JavaScript performance

If you’ve only heard vague things about this deal and want a good summary, I’d read the article by Frank Hecker linked to above.

Most of the obvious and publicly discussed benefits are benefits for the Mozilla Foundation, Firefox, and developers using Mozilla technologies. Personally (as someone involved in ActionScript development) I think this is a really exciting announcement. Over the next day or two I hope to post my thoughts about what this means for the Flash Platform, and why I think it’s a good thing for Adobe (and, via trickle-down effect, for Adobe’s customers). But I’m on dad duty tonight, so that’ll have to wait a bit =).

(via Zeh Fernando)

He gave an example of what he wanted to do, from his message:

var aList [0]:MyClass; // Gives error.
var aAssos [“index”]:MyClass // same
var aAssos [“index”]:MyClass = new MyClass(); // isn’t permitted
because you’ve got to initialize variables before assignate value,
indeed with mtasc.

Essentially (if I understand correctly) he wants to be able to specify a type for elements of the array or associative array, and have the compiler check that only instances of that type are added/retrieved from the array. Unfortunately this doesn’t work the way you might expect it to if you are coming from a strongly-typed language like Java/C++/C# etc.

(It’s also possible that he just wants to specify the type of the data and put it into the array in one step, in which case you can just use the third line but without the :MyClass, or else you can initialize the instance as a separate variable and then assign that variable to the array.)

Background

First a little background. In ActionScript, there are two built-in types that are commonly used to hold a “collection” or array of data.

The Array type is like arrays in most languages — items are accessed using an integer index. However, unlike most strongly typed languages, the Array type in ActionScript allows you to store elements of any type in the array:

var aList:Array = new Array();
aList[0] = 5; // assigning a Number
aList[1] = "hi there!" // assigning a String

Note: Since this article was originally posted I have made some changes to the next several paragraphs to help clarify these examples, based on some helpful feedback on the MTASC list from Nicholas Cannasse (the author of MTASC).

ActionScript doesn’t have a specific “associative” array type, one where you use a string value as the key rather than an integer. However, in ActionScript the basic Object type behaves as an associative array, so the most common approach to creating an associative array is just to use an Object. You can still use the square bracket array access operator “[]” to access the elements of the “array.” In actuality you are just using it for dynamic property access rather than as the array access operatornote 1 — but the end result is the same. Like with the Array, you can store any type of object as an element of your associative array Object.

So a general rule of thumb is that in ActionScript any time you use the [] operator to retrieve a value, the return type is Object. If you want to have stricter type-checking for values retrieved from an Array, you need to cast the return value to the expected type if you want to get type checking for that variable:

var myArray:Array = new Array();
var someObj:MyType = new MyType();
myArray[0] = someObj;
var someVal:String = myArray[0].methodReturnsNumber(); // return type not checked
var otherVal:String = MyType(myArray[0]).methodReturnsNumber(); // return type checked
var someVal2:Number = myArray[0].nonExistentMethod(); // doesn't check whether method exists
var otherVal2:Number = MyType(myArray[0]).nonExistentMethod(); // checks whether method exists

In this example, the lines where the Array element is cast to MyType (5 and 7) will raise an error (in MTASC or the Flash MX 2004 compiler), but the other lines will fail silently. In fact, as Colin Moock points out in Essential ActionScript 2.0, even by casting the value you are only getting minimal type-checking. When you cast a variable in ActionScript, the compiler (and the Flash Player) blindly trust that the cast is correct. For example, look at this code:

var myArray:Array = new Array();
var someString:String = new String("asdf");
myArray[0] = someString;
var someVal:MyType = MyType(myArray[0]).methodReturnsNumber();
trace("someVal = " + someVal.toString()); // prints "someVal = undefined"

The compiler does not check that the object being retrieved from the Array is actually an instance of whatever type you are casting it to, and the improper cast does not cause an error at runtime eithernote 2. (Unfortunately there are very few things that cause runtime errors in the Flash Player — in almost all cases things just fail silently.)

The big downside to this for anyone who is used to working in a language with typed arrays is that you can’t easily get compile-time type safety in ActionScript with Array (or Object used as an associative array). There is no way to designate that an array should only hold values of one type, and have the compiler give an error if values of other types are added or if retrieved values are assigned to variables of the wrong type.

Solution 1: Basic typed collections

The easiest solution is to create your own typed collection that has strong typing for adding and retrieving elements, that just wraps a standard Array for storing the data.

A simple collection class that only allowed MyType instances to be added/retrieved would look something like this:

class MyTypeCollection
{
	private var _innerArray:Array;

	public function MyTypeCollection()
	{
		_innerArray = new Array();
	}

	public function addItem(item:MyType):Void
	{
		_innerArray.push(item);
	}

	public function getItemAt(index:Number):MyType
	{
		return MyType(_innerArray[index]);
	}
}

There is a bit of awkwardness with this because you have to use addItem() and getItemAt() to add or access a particular item. Unfortunately as far as I have been able to dig up there isn’t a way to be able to use the [] operator to access the elements of your array. Sorry, no operator overloading in ActionScript 2 =(. But with a good editor with code hints, the extra typing is minimal, and to me the extra type checking is worth the trouble.

Of course, this only allows you to add and retrieve values from the collection. If you want to remove items, you need to add another method; if you want to find out how many elements are in your collection you need to add that too; pretty soon it gets to be a lot of code.

Solution 2: Heavy-duty typed collections

If you find yourself wanting to do this a lot (like I seem to), you may find it helpful to have a base class for a typed array that already has most of the functionality built in. Then to create your strongly typed collection class, you only need to write the methods that actually require strong typing, and just inherit the rest from the base class.

In all their kindness, Macromedia has written just such a class for us to use, the mx.utils.CollectionImpl class. Now before you tell me I’m off my rocker and there is no such class in the mx.utils package, read this footnote.

To create your own CollectionImpl subclass, you need to override the methods that actually use your specific type either as a parameter or as the return type. That means your subclass has to include these five methods:

• addItem()
• contains()
• getItemAt()
• getIterator()
• removeItem()

Okay, so maybe this sounds like more work than we bargained for. But it’s really not as bad as it sounds. Take a look at this sample CollectionImpl subclass to see a real example of what you would have to include in your subclass.

You also need to create your own subclass of mx.utils.IteratorImpl, to use in the getIterator() method. In your IteratorImpl subclass you will need to override the constructor and the hasNext() method. You can take a look at this sample IteratorImpl subclass to see what it needs to have.

If you save a copy of these sample files, all you really need to do to create your own typed collection is do a find/replace in those two files, replacing the text “MyType” with the name of the class that you want to be stored by this collection.

Solution 3: Somewhere between basic and heavy-duty

If you don’t want to do quite so much work, I have created an alternative base class for collections that only has three methods you need to overload — addItem(), contains(), and getItemAt(). It doesn’t use/require an Iterator, so you don’t have to create an IteratorImpl subclass either. If you are interested, here is the source for the TypedCollectionBase class. A sample of what a subclass would look like is in this sample TypedCollectionBase subclass.

Solution 4: AS2LIB’s TypedArray (Extra-heavy-duty)

Finally, (as Pavel Simek suggested on the MTASC list) if you want to jump in with both feet, the AS2LIB ActionScript framework includes a TypedArray class which handles a lot of this checking as well. From a casual glance, it appears that this type checking is done at runtime rather than compile time — but I could easily be wrong on that one, as I have not actually tried it out.

So there you have it — a variety of options for working around the type freedom that is inherent in ActionScript’s built-in Array class, leading to lovely compile-time type checking — which I will tell you resoundingly, makes it so much easier to debug your ActionScript it is incredible.

Notes

After all, it wouldn’t be me if I didn’t have more to say…=)

Note 1: Using Object as an associative array

The truth of the matter is that when you use an Object as an associative array, you are really just using the [] as a dynamic property accessor rather than as an array accessor. Consider this example:

var myAssoc:Object = new Object();
myAssoc["index"] = 7;
myAssoc.index2 = "hi there!";
trace(myAssoc["index"]);  // prints out 7
trace(myAssoc.index); // prints out 7
trace(myAssoc["index2"]); // prints out "hi there!"
trace(myAssoc.index2); // prints out "hi there!"

The “element” is really just dynamically added as a property on our Object instance, and can be accessed just the same using the dot operator as using the [] operator. This works for any class that is declared as a “dynamic” class — properties can be dynamically added and removed from instances using the [] operator or the dot operator.

In fact, I believe that in the underlying guts that is how the Array type works, too (note that Array is defined as a dynamic class). When you add an element to an Array with an integer index, behind the scenes a new property is created on the Array with the name of that integer index. Of course, you will get a syntax error if you try to access the property using dot syntax (e.g. myArray.0). However, when you use the debugger in Flash you can see that new properties “appear” when they are added. The screenshots in the sequence below show how the properties are added to the Array as we step through the code.

An Array “myArray has been defined and two elements [0] and [1] have been added; notice they appear in the tree just the same as any other object property in the Flash debugger.

Two properties, “index” and “index2”, have been added to the array using the dynamic property access operator []; notice that the debugger doesn’t make a distinction between the named properties and the numbered array elements.

Note 2: Type checking at runtime

Fortunately, there is a way that you can check the type of a variable at runtime, and if you aren’t going to create your own strongly typed collection class I suggest you use this approach instead. ActionScript has an instanceof operator that can be used to check the type of an object. The best way to use this with array elements is to assign the retrieved value to a variable of type Object, then test that object using instanceof:

var myArray:Array = new Array();
var someObj:MyType = new MyType();
myArray[0] = someObj;
var someOtherObj:OtherType = new OtherType();
myArray[1] = someOtherObj;
var someVal1:MyType = myArray[0]; // the correct type
var someVal2:MyType = myArray[1]; // not the correct type
var someVal3:OtherType = OtherType(myArray[1]);
var someVal4:Object = myArray[0];
var someVal5:Object = myArray[1];
var test1:Boolean = someVal1 instanceof MyType; // true
var test2:Boolean = someVal2 instanceof OtherType; // true, but should be false
var test3:Boolean = someVal3 instanceof OtherType; // true
var test4:Boolean = someVal4 instanceof MyType; // true
var test5:Boolean = someVal4 instanceof OtherType; // false
var test6:Boolean = someVal5 instanceof OtherType; // true

Test 2 fails because the retrieved value is assigned to a variable of the wrong type, and the silently failing cast has already taken place. Compare this to test 5, where the retrieved value was assigned to a variable of type Object. In that case instanceof returned the correct value. Moral of the story: if you’re going to use instanceof, make sure your “test” variable is typed as Object. If instanceof succeeds you can then cast the value and use it as the correct type, like this:

var myArray:Array = new Array();
var someObj:MyType = new MyType();
myArray[0] = someObj;
.
.
.
var testVar:Object = myArray[0];
if (testVar instanceof MyType)
{
	var typedVar:MyType = MyType(testVar);
	// do something with typedVar
}

Of course, be sure to read the caveat about instanceof and instrinsic types (Boolean, Number, and String) in the documentation. Essentially, instanceof will return inconsistent results for those types depending on how their original value was assigned. For complete checking of those types, you need to check them using instanceof and the older typeof also, making your code look like this:

var myArray:Array = new Array();
var someString:String = "asdf";
myArray[0] = someString;
.
.
.
var testVar:Object = myArray[0];
if (testVar instanceof String || typeof(testVar) == "string")
{
	var typedVar:String = String(testVar);
	// do something with typedVar
}

Note 3: getting the mx.utils.CollectionImpl class

The mx.utils.CollectionImpl class doesn’t come with Flash; instead, it is included in the source code for the Flash Remoting Components, which anyone can download for free from the Flash Remoting Components page. The link is a little hard to find — there are several links to download the MX 2004/AS2 components in various languages, and then down at the bottom of that section there is a small section titled “Source Code for Macromedia Flash Remoting for Flash MX 2004 ActionScript 2.0”. Under that heading you will find a download, which contains the ActionScript class source code (you don’t actually get the source by downloading the components, which is a puzzle to me).

Create Elegant Code with Anonymous Methods, Iterators, and Partial Classes (C# 2.0)