Frankly, I would prefer not even think about a new event mechanism right now before fixing all other bugs and having all Spark components. Plus, the simple fact that people won't be able to upgrade easily is a huge problem that isn't being mentioned here. I say that we stay the course for now until the codebase is stable, then we can start to address these issues.
M On Mon, Jan 16, 2012 at 5:48 PM, Rick Winscot <rick.wins...@gmail.com>wrote: > Response inline... > > > On Monday, January 16, 2012 at 5:19 PM, Michel Boudreau wrote: > > > I don't really see the reason to have Signals added to Flex, especially > if > > it's already possible to just add it as a separate library. We can't > > > > > > Performance is a _very_ good reason. Adopting it into the framework means > better maintenance, visibility, and interoperability. > > change the fact that Events are use for the UI and we'd want that because > > of the bubbling/capturing. Last I checked, this cannot be achieved with > > > > > > NativeSignal ( yes it can be done - it's optional ) > > Signals. I understand that signals is faster for application messaging, > > but Parsley solved this problem easily by simply using a custom > dispatcher > > which does class type checking instead of even string checking. In the > > end, the "events" being used are simple final classes (called messaging > > classes) that don't extend Event. I prefer this approach because of the > > > > > > Class type-checking === coupling. This can drastically reduce your miles > per gallon in app development and can pigeon-hole you into heavy > dependency. If you're working with modules, creating plug-ins, etc. you're > going to want to ditch that school of thought pretty quick. > > fact that you can have inheriting messaging which works very well with > the > > message handlers. > > > Heavy hierarchies is part of the problem... > > > > > M > > > > On Mon, Jan 16, 2012 at 4:57 PM, Aladin Scott <ala...@centrepede.com(mailto: > ala...@centrepede.com)> wrote: > > > > > I second that, AS3 Signals is awesome. I haven't used native events to > > > communicate outside of a parent class since using Signals. > > > > > > Aladin Scott > > > > > > On Mon, Jan 16, 2012 at 9:39 PM, Rick Winscot > > > <rick.wins...@gmail.com(mailto: > rick.wins...@gmail.com) > > > > wrote: > > > > > > > > > > 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 > > > > > > > > -- > > Michel Boudreau > > > > "If at first you don't succeed, use a bigger hammer." - Unofficial motto > of > > the Royal Electrical and Mechanical Engineers > > > > > > > -- Michel Boudreau "If at first you don't succeed, use a bigger hammer." - Unofficial motto of the Royal Electrical and Mechanical Engineers
