Signals may spell the death to my Commands as I know them

Back when I wrote my Command library I was doing a lot of calling of commands.  It actually stems from the Commands/Delegates I created for the Facebook AS3 API (which have since been removed; which I think is a shame).  Essentially the greatest benefit I got from my commands with the ability to do this:

instead of this:

That got rid of a lot of code for me and made me very happy.

Boss: Jason, how many lines of code did you write today?
Me: (proudly) Negative two-hundred-sixty-nine!

Just kidding. My boss has never asked me how many lines of code I wrote.

But the less code I have to write the more time I get to spend blogging. Or playing Super Mario Bros Wii. Or closing bugs. And the easier it is to tell what the HELL is going on. And the less likely I’ll be to forget to remove listeners. All good stuff right?

Well the benefit only worked if I was extending one of my AsyncCommand classes. Which worked pretty well since most of the stuff that I wanted to work that way was “business logic” stuff that I stuck in a command. I would execute and wait for the result.

If the result was bad then I could just check the .success property and put a little logic in the callback handler. But wouldn’t it be cool if I could do that for all KINDS of events? And by “events” I mean “Stuff Happening” not dispatchEvent(new Event());

Well Robert Penner’s Signals is almost exactly that. Imagine an object that has a number of things that could happen. Probably not hard; most of you have pretty good imaginations. For the case of my commands it could be complete and error. That command would then have a .completeSignal object and a .errorSignal object. These are Signal objects to which I can subscribe. Usage would be something like this:

Then when the command has finished running the completeHandler is called. And it’s not passed an event from which I have to glean what tossed the event and type it. it’s the strongly typed command that dispatched the signal . . . just like my addCallback() method did!

So I’m thinking, since being able to listen for lots of things happening is better than listening for ONE thing to happen . . . well that might just spell the end to the Peanut Butter Commands. At the very least I think I might re-factor things to use Signals instead of my own home-grown callback handling logic. I’m just beginning to play with Signals but I’m already very pleased with how it makes my code look.

I’m beginning to question the idea of calling commands directly anyway. I mean it sure is damn handy. I hate tossing events to get stuff to happen; it just seems like a lot more code to me. Usually, in the software I write, the ONLY thing that cares about when a command is finished is whatever called the command in the first place. And besides I can always let people know that a command finished (via an event or a signal) right?

There has been some active talk on the RobotLegs group about combining the powers of the Legs and Signals. It sounds like it’s going pretty well and I’m really interested in playing with it (once I get a bit more code written that I’m paid to write). My distaste for Events drives me to find any solution I can to get rid of them in as many places as I can.

By the way, nice work Robert.