Do you see the bug? The variable 'channel' is accessed before it is defined. This is not a compile-time error. At runtime the value of 'channel' is null before it is declared.

There's plenty of other gems, I assure you. (Did you know someDictionary["hasOwnProperty"] = 1 will fail at runtime because dictionaries have a method called hasOwnProperty and dictionary methods are keyed in the same place as their elements? GENIUS.)

I didn't mean the bug is in the compiler. The bug is in the code. It just wasn't caught because of the declare-after-use-is-ok semantics. (I was re-arranging code at some point and introduced it by accident.)

Wait, do you mean the compiler will move the evaluation of sound.play() along with the declaration? That sounds insane! Just to be sure, could you indicate which of the following is equivalent to the original code?

This, moving the declaration and initialization, "fixing" the bug I thought was present:

It's not Action Script 3, its ActionScript 3.0, if your going to bash something at least get its name right. What your are doing is nice, wrapping functionality into a single class. That's the whole point of OOP, but these Tasks are not going to help in every case. Maybe for some simple tasks this wrapper is great, but what about events that need to be called more then once, or need to be called until a certain condition and then removed? Its better to add the events manually. What about if I want to set up multiple event handlers with different priorities, or event bubbling, If I want an event to bubble how is that handled. You say reading the api is a pain, but your a programmer, its good to read the api, you will understand whats going on and what may happen and how you should handle it. This article is very naive, spend more time with a language and understand it better before you bash it.

I'm sorry I got the name wrong. Omitting the ".0" seems pretty common, but adding the space before "Script" isn't. Whoops. I've updated the post.

If you expect multiple callbacks or you want bubbling or priorities then of course you should use events. Like I mentioned in the post: events are broadly applicable, but tasks are better where they apply. They happen to apply in a lot of common use cases like loading content, waiting, and playing sound.

I just don't see the point of your class. Even for playing sound, which you say its better for, there are so many use cases that your class doesn't handle. Sound progress, id3 data, sample data, all very common but not possible with your Tasks. You reduce things down to a success case and an error case, but this only applies to a small set of conditions. I know you think this class is the best thing in the world, you even took the time to write a blog entry about it. What did AS3 programmers do before this? You are so smart! ...You worked on one AS3 project and have the balls to tell AS3 programmers that their language sucks and this is such a better way to do things, its programmers like you who sometimes make me hate my job.

When I say "better" I mean "easier to use", not "has more capabilities". If you want to play a sound with progress information, that's not well represented by a task because it's not a single eventual result. Use events (or maybe an IObservable equivalent) for that case. If you only care about the sound finishing then tasks are easier/simpler/harder-to-get-wrong-even-by-accident.

You can implement tasks with events, but that doesn't mean it's best to use events when something simpler and more composable will do. There's no need to write everything in assembly code.