i understand your point, but i think you’re holding too much on the CallbackCommand, which is a special convenience, which i dont use very often anymore.
Actually a Command is pretty much different, and you can have arguments on functions again. Let me just explain it on an example. Or 2 as there are 2 (and even more) ways of doing it actually.
For one you could just do stateful commands, which means, that they can hold data. This is not always convenient, but it also has its advantages (when you have to dispatch the same command very often this is of course inconvenient, as you’d have to clone/create a lot of commands, but for larger commands this is actually quite nice)
what i’d do is make for example a NavigationCommand which you give the navigationID where to go to. This comamnd will store this id and the executor just calls an execute(); so it doesnt need to know what is called.
Also in turn the one creating it does not need to know how this is done, cause the command will handle everything.
The Command itself can ofcourse call a lot of functions and they can have arguments.
For one thing you mentioned later imagine for example a LoadCommand, which is maybe not only an ICommand but a special one you could give some data. For example it will load a SWF so it might be an ISWFLoadCommand (or something like that) interface which this command will also implement. you’ll hand this over to your loader and the loader will set the data and dispatch/execute this one. This way the command does not have to fetch the data, and the loader only knows what it needs to know - no more - no less.
So basically by using interfaces you could overcome all those obstacles.

There is also a 3rd way of doing it by using a complete model strategy, which i prefer mostly. I tend to like it to have my application-state in one defined model - everything. So when i stop it, i could just read out that model and i know whats going on (i could also save this, load it, or dump it to recreate bugs user’s caused, etc, and it is fucking nice for any undo/redo functionality)
In this case your commands can store data, but will mostly only get some parameters, but will never store the current state. As soon, as they are executed, they will exclusevly work on the model - for example by giving your command the “place to look” and your loader the “place to store” the data. Actually Loading would then split up into a StoreCommand which is dispatched by the loader (which in turn in some way needs to know where to store - you could use an interface here again so it does not need to know directly, but just sets the data) and a Command which will do the real work on WHAT to do with your data. Splitting it up that way may seem bad performancewise but you’ll get a nice stack of “things which are done” in your application. Actually separating each store, and each work will make any undo/redo functionality you have to implement nicely easy.
The later one would benefit a lot from a database-like model, but for know flash does not have something like that for the web unfortunately. What i’d like to do there is basically store data not directly by accessing the model, but more like you know it from hibernate, where you get an object from the datalayer, modify it, and then attach it back on (like with save(); or if it is disconnected its gonna get a bit more difficult) - this would actually help a lot with binding, where you often want to store a bunch of things in one step and dont fire a single binding before that happens (transaction like). i have already plans to do that, but it’s not an easy project and my time is unfortunately very limited. Actually it would be much better for adobe to pick it up and give us a speedy version of this not completely implemented in as3, but thats maybe just wishful thinking :)

clip.addEventListener(new FrameEvent.LABEL, onFrameLabel);
clip.addEventListener(new FrameEvent.BEGIN, onFrameLabel);
clip.addEventListener(new FrameEvent.END, onFrameLabel);

Otherwise, this is handy. Thanks!

I haven’t checked the performance losses against direct callbacks yet but it shouldn’t be that much slower.

I wanted to point out that commands will be slower than callbacks, which are in turn (much) slower than runnables. I haven’t tested commands, but perhaps they are not so much slower than direct callbacks.

You guys are absolutely right about the convenience of just having one interface. This will have a material benefit in that multiple interfaces will start to bloat up your SWF size.

I think when I first read the article I made the mistake of thinking that the parameters to the callback were going to be passed via Function.apply(), but now see that the extra args are simply for convenience. In my view, it would be better to separate out this extra argument functionality the currying technique, which is rather easy to implement in AS3. If you do this you will find that a command is almost exactly like Java’s Runnable except that it holds a Function variable rather than being implemented by a class with the execute()/run() method. This is precisely the cause of the slowdown. However, as you guys point out, performance is not always everything. This would really only matter in performance-critical code.

About the GC, I really do think that commands as shown above do not help the GC. You point out that the command can be nulled out after it is used, but so could a runnable or a direct callback. Nulling out any of these would result in dereferencing the object holding the callback function and therefore freeing it up to be garbage collected.

Lastly, I think it’s worth noting that the command technique forces all callbacks to take no arguments. This is good for keeping the single-interface design and keeping the callee from knowing about the caller and visa versa, as you guys point out. However, the problem is that this forces the class to expose as a public variable (or getter) what would normally be passed as parameters to the callback function. This leads to a bizarre assembly-style devolution where the extremely useful convention of passing arguments to functions is eschewed in favor of storing a variable and then retrieving it later. This breaks up what is essentially a message like “hey, here is your loaded display object” into a sequence “hey, I finished loading” then “could you give me what you loaded?”. This may force unnecessary storage of temporary values that would normally be simply passed as function arguments in fields of the class. It may also force the creation of getters. Both add a typing, SWF size bloat, and awkwardness. They also make it harder to determine when to get rid of such a temporary. For example, how long do you need to keep it? One frame? One getter call? Forever?.

Thanks for the discussion on this. It’s been fascinating hearing your arguments for a technique I had previously never even heard of. I think that in some circumstances this could be very useful.

Uwe got it right here in another Point than Performance (that is not all so very essential all the time). And i do think we have to differ here, what we want to do. There are several approaches, and each of them has it’s drawbacks. I really believe, that there is no “one fits all” strategy all the time, although the command model works quite well - it also has its problems in some areas. (It can also solve it and speed up like hell, but that will only work good on multi-core models - and flash does not have multithreading yet - except for the asynchronous loads maybe - there we do have concurrency at least)
Command Model CAN solve your speed problem, as it CAN use direct function calls. As Uwe described, CallbackCommand is more like a “convenience command” for hooking up stuff in existing code and to easily make a quick test or mockup, but its not the way of doing it all over your application. Actually Command will change your whole way of thinking about “where to put functionality”. - it will reside *in* your Command.
So making a callback is actually quite weird, as it violates the concept of commands, but for quick testing it is sometimes very convenient.
One nice thing about it is also
When someone dispatches a command - as your view or anyone else. He does not know *which command* it is maybe (he might know, but does not have to) - but when you are debugging YOU SEE which it is. You directly see the command, go there - click - and voila, you see what this command is doing. Not a name - but the code it is executing - directly. You dont look up strange event maps here. This is an advantage over events.
You could say - hey function calls can do that too - well - partly. Suppose you want to give your function some input parameters - then it doesnt work anymore. Suppose the caller should not know about all of them (mostly not any of them). Function calls dont support that without you violating type-safety. One thing you do get are funny compiler errors when finally this function is called in a wrong way - and it will.

Both these situations are solved by Command AND Runnable equally. And they are both faster, as soon, as they dont use Callbacks. Only thing about command are some special things all commands have in common.
For one there is execute();
you have it - always. (There are people that use parametrized execute() methods - please god, let them suffer for their sins - it is a way of doing stateless-commands - but it hurts so much as you completely lose control over your code again - there are other ways of doing that, which are completely typed and do not involve casting of events into something else - hello cairngorm etc)

oh i got broken off here

another thing i might add is, that i remember runnable from java, but it was mainly used for threads&stuff. but basically runnable with having only the interface of run(); as you’ve shown is basically the same, named another way and definitely better than events :)

But when it comes to garbage collection I’m not sure about it. To make use of your approach you have to assign the whole object to a caller. Being referenced there you cannot destroy this object since it’s locked until you kill the reference.

By using a method as parameter you can null the function reference right after execution (if you need it just once -> e.g. in a loader) and the command itself can be destroyed. (And the object with the referenced method should be destroyable all the time since it’s just a method reference which can be null)

OR

you can clone it and use it again (e.g. for a menu with a bunch of menuitems) which need to stay clickable.

But in my opinion the main advantage is the flexibility because you’ve got just one Interface -> ICommand instead of several for different purposes. The CallbackCommand is some kind of a side product because it’s not really a command - it just acts like that. Instead you should use those “real” commands (ASyncCommands, MacroComands etc.) which was the initial idea of doing it that way.

That it became faster compared to events was nice too. I’m also glad to read other people fighting the same interests and issues. :-)

Additionally, I don’t think this helps with garbage collection. If the Function that the CallbackCommand holds is a non-static method of a class, like most functions are, it will have an implicit reference to the instance of the class the method is associated with, ie. its this pointer/reference. You’ve essentially converted this:

MyAPILoader -> Function (callback) -> TheClassUsingIt

To…

MyAPILoader -> CallbackCommand -> Function (callback) -> TheClassUsingIt

If this were not true, how would CallbackCommand know which instance of TheClassUsingIt to call the method on?

I’d be interested to hear your thoughts on these two concerns of mine. Also, it’s nice to know that there are others out there who share these niche concerns of mine. :)