/customers/iconara.net/iconara.net/httpd.www/blog/wp-content/plugins/wp-super-cache/wp-cache-phase1.php Iconara » Review of MTASC

Review of MTASC

I’ve started using the Motion-Twin ActionScript compiler (mtasc), and I thought I should share my thoughts on the subject.

My first impression of mtasc is that it doesn’t suck. It might be a low standard to aspire to, but seriously, there is hardly any competition.

The problem with the Macromedia compiler (mmc) is that it’s paintfully slow. It’s also somewhat stupid. mtasc, on the other hand, is blazingly fast and has some nice features, too.

The complications

There are, however, a number of complications. I can’t recommend you to use only mtasc, you must compile with mmc once in a while for a number of reasons.

  • mtasc can’t compile the flash.* nor mx.* classes, so unless you compile with mmc you can’t do very much animation. You get warnings that they have #include statements (which aren’t supported by mtasc).

The good thing is that all these problems are solved if you compile with mmc once in a while, and the #include problem can be solved by editing the classes by hand and removing the include (it’s only including version info anyway, not anything that will break your application).

There are also a few annoyances, or at least things that work differently:

  • The scoping is different, static variables are not accessible inside closures (anonymous functions), you have to use ClassName.variableName to access them. It’s not wrong, just another interpretation of the scope a closure sees.
  • Another scoping issue is that a local variable will be used in place of an instance variable with the same name, this is actually expected, but different from mmc. I’ve had problems that seemed totally inexplicable, where compiling with mtasc worked fine, but after compiling with mmc the application wouldn’t work. No compiler warnings from either compiler, just different interpretations on what’s right.
  • As stated above, #include is not supported. This is neither an annoyance nor a problem, since you shouldn’t use it anyway, but it’s good to know that it’s not possible to use. If you have a #include in your code it will generate a warning and not an error, but nothing will be included, so you may experience strange behaviour.

The good stuff

Besides being fast, mtasc has some nice features. Take for example the inference type checking: the compiler’s type checker will remember which type a variable has depending on which type it got when it was first assigned. Example:

var list = new Array();


This will generate an error in mtasc, since Array doesn’t have any method called popp. mmc wouldn’t say anything since it’s to lazy to look up the type of the variable, you’d have to declare it explicitly.

Another nice feature is that mtasc can do a compile time substitution of the trace function and replace it with any function of your choice. The custom function will also recieve the full name of the method containing the trace call along with class name and line number.

mtasc has a hack to make arrays type-safe. I say hack, because I think it’s a hack. It looks like this:

var list : /Number/ Array;

On the other hand, it can get by as extra documentation, which makes it less of a hack.

Last and maybe least, mtasc can generate warnings for imports that are not used. This can be handy for cleaning up the import section of your class files. I’m sure that mtasc (and perhaps even mmc) is clever enough not to include classes that are only imported but not used in the resulting SWF, so this is just for clarity and cleaning.


This has hardly been a thorough review of mtasc, but I hope you are somewhat interested in it. I use it always, and I feel it saves me time since I don’t have to switch to Flash and watch the progress bar forever everytime I want to compile. I can even run the compilation just to do syntax checking and type checking, which I never did with mmc since it was too slow. I coded until I had something I wanted to test, then I compiled, fixed errors, compiled and so on until I could test. To compile just to do a syntax check would break my flow, but this is not the case with mtasc, instead it has become a part of my flow.

Just remember that every now and then you have to compile with mmc, otherwise it may not be possible for your colleagues to use your code.

A footnote: mtasc will not be available for ActionScript 3.0, so it’s somewhat of a dead end. On the other hand, the new compiler in Flash 9 seems much better.

Another footnote: the author of mtasc has another project, called haXe, which is an alternative programming language similar to ActionScript 2.0, but with the haXe compiler it can be compiled into SWF for the Flash Player, JavaScript for web browsers and Neko for server-side applications. It doesn’t look so bad, but ActionScript 3.0, Flash 9 and Flex 2 seems better.

Leave a Reply