Yishay Weiss, I have very, very complex controls on my Flex application because these controls must be compatible with many use cases. I see now the valuable on composition approach. I end up with an insane small version on Royale that will require many beads that each one will use events that I want to make sure to remove the listeners. As I saw a helper for add listeners, I thought that a remove also makes sense but it's not an issue for me. I can remove it the standard way :)
Yishay Weiss <[email protected]> escreveu no dia terça, 20/10/2020 à(s) 18:04: > Most of the times I just implement IBead rather than extending Bead.as and > I’m not sure how much it is being used, but it should probably be kept > small. I personally have not needed unlistenOnStrand. Hugo & Carlos, when > was this necessary for you guys? > > > if we have listenOnStrand, shouldn't we also have unlistenOnStrand ? > > Not necessarily. I think we should provide the minimal interface that is > good enough for the most common use cases. > > As I see it, a solution that does not compromise PAYG is to create > function class unlistenOnStrand which can be imported if need be. > > From: hferreira<mailto:[email protected]> > Sent: Tuesday, October 20, 2020 11:20 AM > To: [email protected]<mailto:[email protected]> > Subject: Re: Added helper function on Bead.as to make beads cleaner > > Hi, > > What do you thing about adding this to Bead.as ? > > /** > * Helper function to remove event listener without the need for > casting > * @royaleignorecoercion org.apache.royale.events.IEventDispatcher > */ > protected function > > unlistenOnStrand(eventType:String,handler:Function,capture:Boolean=false):void > { > (_strand as IEventDispatcher).removeEventListener(eventType, handler, > capture); > } > > I know that Bead.as should be keep simple but if we have listenOnStrand, > shouldn't we also have unlistenOnStrand ? > > > > -- > Sent from: http://apache-royale-development.20373.n8.nabble.com/ > >
