incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Winscot <rick.wins...@gmail.com>
Subject Re: Flex - lightweight event handling
Date Mon, 16 Jan 2012 22:48:57 GMT
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 <aladin@centrepede.com (mailto:aladin@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.winscot@gmail.com (mailto:rick.winscot@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
> 
> 



Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message