With regard to Signals vs. Events... Rob provides a bridge called a "NativeSignal." To Quote from his blog ---
Why not use EventDispatcher for the actual dispatching but wrap it in a Signal facade? Presenting the NativeSignal class, which lets you have your cake and eat it too. Take any EventDispatcher, e.g. Sprite. Create a NativeSignal that targets an event of the dispatcher: // in a subclass: click = new NativeSignal(this, 'click', MouseEvent); // or decorating an instance: click = new NativeSignal(theDispatcher, 'click', MouseEvent); Enjoy the Signal APIs and features. Dispatch from the NativeSignal or the EventDispatcher. Both use Flash's native dispatchEvent(). If you're hesitant to put your trust in new dispatching code, or you want to keep your EventDispatcher options open, this is the gateway drug for you. You don't have to give up anything. All the native functionality stays, and the ISignal interface can be piped in like frosting, wherever you like. Doesn't that sound delicious? What of Signal performance? http://alecmce.com/as3/events-and-signals-performance-tests The above charts are a little old - Rob has made a few commits since that have added another 30 - 40% improvement. The primary takeaway is that Flash Events for UI interaction are ok ( a necessary evil? ) but are a very poor choice for inter-application communication. Efficiency in communication becomes more and more important as the size of the application increases. -- Rick Winscot On Monday, January 16, 2012 at 4:17 PM, Omar Gonzalez wrote: > I'd definitely be interesting in exploring this idea. I had a lot of > internal debating with myself over whether to use native Event objects or > as3-signals when I wrote my MongoAS3 library. I ultimately chose signals > because I enjoy their ease of use and payload type-checking runtime errors. > > -omar
