Barklund.org

I have been doing ActionScript 3 projects for quite a while, but every now and then I (as well as many others in the trade) have to switch back to AS2 or even AS1 – the line between them is quite blurry really in retrospective. When doing AS3 projects, there are many features that really come in handy, but it is only when you don’t have them available, that you really find out which are the true improvements, that you cannot live without, and which are just nice little tweaks, that make your everyday scripting easier.

The latter category includes e.g. the for-each-in construct, different number types, class introspection or built-in class look-up by string, but these are my top 6 AS3 features, that I find myself constantly missing when fixing or improving scripts in older versions of ActionScript:

Number 6: Default values for parameters

if (!scale) scale = 1;

It is very simple, it doesn’t really look nice (at least the first couple of times you read/write it), but it gets the job done and it is consistent with how other languages does it. If it is the best possible choice for implementation, I cannot really say, but I wouldn’t be without it now that I have it – though I can easily think of improvements.

Okay, you are going to ask anyway, so here it is: It can be greatly improved by adding the ability to add parameters by name like in Python – e.g.

ftp.connect(host="www.server.com",username="administrator",password=password_input.text);

It looks a bit strange but it is a great improvement – just compare it to how you need to specify the third (useCapture) and fourth (priority) arguments to addEventListener whenever you need to specify, that you want it to use weak references (the fifth argument set to true) – it does not look that good and could be a lot easier to use with named arguments.

Number 5: E4X

firstChild.firstChild.childNodes[i].lastChild.firstChild.attributes.id

XML-based configuration files have been around for ages. I have done banners back in Flash 5, that used external configuration files for texts, layout, flow, paths, connection properties or something similiar. Of course, back then you always loaded the ignoreWhite script (wasn’t it XMLNitro.as from Branden Hall?), but you still had to either create your own serialization schemes, load someone else’s or go through the staggering pain of navigating through the XML-node tree through simple node references without knowing their names in advance.

With E4X we have been equipped with XPath-like traversal schemes, that still allow for basic node traversal, but makes it infinitely much easier to reach that specific node, that you need and know the name (and maybe some of the path) of.

Number 4: Instantiate movieclips – even across SWF’s

No more duplicateMovieClip madness

I did a large isometric chat world in the good old Flash 5 days (and it only just recently got improved – which meant doubling the version number from Flash 5 to Flash 10 – now that is rare) and split code out in several FLA-files compiled to several SWF-files. But as everything needed to be possible to lay in-between each other all graphics needed to be in the same SWF-file. Which meant they had to come from the same FLA-file (unless we used swfmill or something similarly fancy, which were in their infancy back then). Everything had to be exportable from the library and as items in the library couldn’t really be linked to classes directly, all item script had to be placed on the timeline. Of course it was a big mess and already back then we were hoping for a better way of loading content from external files (did anyone ever find out how to utilize “shared libraries” for actual production value?).

And now we have this feature – it is so much better. Create a symbol in a library in any FLA-file, load the resulting SWF-file in your production and instantiate any symbol from it and attach it anywhere you like. Clean and beautiful and exactly what we needed back then – and when going back, you really get that feeling again.

Number 3: Error handling and run-time validation

When it doesn’t say anything, does that mean no error happened?

Imagine having put your AS2 production live, have it loaded in the browser and an error happens (because you visually can see that something is wrong) – how the h¤ll do you find out what happened? There were the old debugger, but it was crap – simply crap. You could only hope that you had enough trace’s spread around to debug based on your flashlog.txt file.

With AS3 we got run-time validation. If something is wrong, we (most of the time) get a huge ugly error popping out. It might look bad, might give bad user experience (if so, they ought to stop using the debug player though) but to the developer it gives the necessary feedback (thank you stack trace). And not to mention all the other advantages that run-time validation gives.

Number 2: Function scoping

I simply hate delegate.

When doing pseudo-OOP like in ActionScript 2 (or AS1 or JavaScript), you constantly need to bind your functions as methods of your class instances in order to be sure, that if passed by reference, they are invoked in the right place. In ActionScript 3, this is no longer necessary. Basically, when passing a reference to a method of a class to someone or somewhere else, the scope of the method (being the originating instance) remains intact:

var a:Sprite = new Sprite();
var b:Object = new Object();
var c:Sprite = new Sprite();
b.addChild = a.addChild;
b.addChild(c);
trace(a.numChildren); // traces "1"

Anyone using AS3 knows this by now, but this was just to re-iterate and give an example.

Actually, it is not function scoping. It is more about creating a clear distinction between functions and methods. Functions are anonymous and created inline and don’t really use a “this”-scope but a reference scope. Methods are attributes of classes and are always invoked on instances of the class.

It does remove some “scriptability” in ActionScript, as currying and similar tricks aren’t as useful anymore and actually you never use “normal” functions at all – only methods. But intelligent use of patterns can have the same effects as such minor tricks and though they require more typing, they produce cleaner and often more intelligent, re-usable code. But that is the target of a whole other discussion.

Number 1: The display-list instead of depths

myClip.getNextHighestDepthLowerThanTheDepthOfTheMenu()

Depth. The most annoying part of AS2. I didn’t realize it back then, you were so accustomed to writing foo.createEmptyMovieClip(“myclip”, foo.getNextHighestDepth()) and then swapDepths’ing it all around afterwards, but now that I don’t need it anymore but have to go back to using it – it is so time consuming.

At first, the display list sounded a bit scary to me and the very first demos of the language explaining MXML and layout schemes gave horrible flashbacks to the script-consuming “layout engine”, that Java and SWING employs. But most of us never use any of those layout schemes, simply add items to stage on coordinates with the display list being the best tool to ensure proper depth management. Thank you!

Please leave comments, if you have other features than you constantly find yourself missing, or in other ways believe you can improve this list. Oh, and if you have suggestions for other lists, then by all means add them here.

Related posts:

1. Minor change in handling NaN positions in Flash Player 10,0,22
2. Advanced E4X – Assignment to XMLLists