My Take on ActionScript 3 shortcomings

I have been playing with ActionScript 3 lately and I will say upfront that I like it, it does what it’s supposed to do pretty well: Provide a thoughtfully designed language targeted specifically at the Flash platform.
But it has also been touted as an object oriented language with optional compile-type checking and so I had certain expectations when I took the language for a spin, with a eye towards developing large (as in a few thousand classes) application.

Here are my thoughts on what is missing and why I think those features should get implemented as the language matures and tries to appeal to a wider range of developers (think non-”traditional” one who have been working mostly on non rich web application application). By the way, I don’t consider myself a language expert and my opinion may evolve as I write more ActionScript code.

- No support for multi-threading. I feel that this is the most glaring shortcoming. I understand that it can get tricky for any language belonging to the JavaScript family (I guess it’s more appropriate to use ECMA family of languages here, or ECMA-compliant, but ECMA is a weird acronym that just doesn’t round right) to support threads when it’s meant to run within many browsers and on many different operating systems but this could be one of the main reasons why some enterprise projects may shy away from ActionScript 3. But then again AIR is a desktop solution, and still no threading. Maybe Adobe and the community should seriously reconsider this missing feature. haXe could be considered as a model (http://haxe.org/doc/neko/threads?lang=en)

- Limited native types. You just get 5 of them: String, Boolean, Number, int and uint. It may be an indication of the language purely dynamic origins where such considerations were not important. And what’s with the inconsistent use of cases: String and int (upper and lower)? I guess it’s for legacy reasons. You could argue that if you really need to make a distinction between double and float then maybe AS3 is not the right tool just as you could argue that for people who want to use AS3 for the visualization of complex analytics such a distinction does matter. There is a lot of room for debate here.

- No overloading allowed for constructors, methods, or even between a variable and a method. This is a limiting factor in larger OO applications. Overloading constructors, for example, greatly contributes to the usability of your class. On the other hand I do like the mandatory inclusion of the ‘override’ keyword in subclasses, in line with the trend of other languages (or Java’s @Override annotation; for Java it’s too late to enforce it as a keyword)

- No abstract classes, but there are interfaces. Again, that’s a missing piece in the arsenal of an OO language as interfaces are not exactly the same thing.

- Interfaces can only declare methods, not variables or constants. This restriction can be lived with, but why?

- An .as file must have only one externally visible (public or internal) class or function; this a compiler (mxmlc) restriction, not an AS3 restriction per se. This can become annoying for a file defining global utility functions.
It’s worth noting at this point that there are a few ActrionScript compilers out there, a tribute to the vitality of the community, but that’s a little bit off topic in a post titled “AS3 shortcomings”, isn’t it? So I’ll just add that MTASC is great, but specifically geared towards AS2 with no plans for AS3 as they announced that they are focusing on haXe (by the way they are the creators of haXe). I never tried swftools, though I should. Maybe this bullet point will prove invalid.

- No Generics, which gives the language a very pre-Java 5 feel. This is felt even more acutely given the many resemblances to the Java language. They could have been inspired by GJ, the work on STL, etc… For some reasons it has been left out. This may not be necessarily hurtful for people used to work with the AS3 Array class (it’s a heterogeneous collection of objects) but you do feel their absence when you are trying to write a method where arguments can be of a certain type and all of its descendants but no more, i.e. you don’t want to necessarily resort to the * notation.

- Speaking of Array, what’s with the delete operator? It does not really delete (for that you are better off using splice()). Maybe that’s what happens when you try too hard to come up with a unique syntax for your language. At this point I am tempted to say that we should just stick to the C++ syntax, but to each his own and this type of debate can easily degenerate into futility, so let’s leave it that: The ‘delete’ operator does not delete an array element (when used in the context of arrays), it merely sets the element value to undefined, and that’s misleading.

That’s it for now, I will probably post a follow up where I explain why I really like the event dispatching model and some of the language functional features.