Hi Harbs El mar., 19 feb. 2019 a las 18:30, Harbs (<harbs.li...@gmail.com>) escribió:
> > > Yes. Basically, you can ask any bead for a list of its interests, and that > list is used to both add and remove bead references in the strand. The bead > does not need to clean itself. A ututiliy method can completely strip a > bead off a strand including all references necessary for notification. Take > a look how that’s done here: > > https://github.com/apache/royale-asjs/commit/1b2a45c91397e485be93d56925f2c31417726bb7#diff-5f2744f9620d90c13d8759c4a326e8cbR27 > > I think most of the time, beads would need some code on its own that should be run when removed, but anyway maybe that's no a problem > > Benefits: > 1. Beads do not reference the Strand at all. All references are from the > Strand to the bead. 2. Event listeners have a lot of indirection when they are launched. It’s > much easier to step through notification dispatching. > 3. Because notifications have no callback passing, there’s less chance of > memory leaks due to callback references. > 4. Currently, the framework has countless uses of “_strand as > IEventDispatcher”. This is not something I’m thrilled with. Notifications > make things much cleaner. > 5. There’s a single entry point for notifications in a bead. I think that > makes things easier to grok. > 6. I think notifications makes it cleaner to use a single bead on multiple > strands (if so desired). > ok, seems good > > > 4.- Do you see some drawback? or what's the flaw points we can get over > the > > traditional event dispatch system? > > Here’s the drawbacks that I see: > 1. We’re adding some additional weight to strands and beads. > in some places I think we should not be extremely purist. > 2. Some of the events that we’re dispatching are used on different beads > such as “layoutNeeded” where we’re laying out children relative to their > parents. Cases like that will be needed to be handled. > > Regarding #1. I think the additional weight is more than offset by code > saved by not having to attach so many event handlers. > Regarding #2: Events can still be used when they make sense, or maybe > there’s some other way to handle layout issues. Not 100% sure on the best > way to handle that problem. > > > Sorry, if I need more explanation, but I still trying to figure what's > all > > about. Hope with your explanation I'll see the big picture > > For me seems ok. I understand that although we add this we always can rely on the old system, and migrate if we want different parts little by little right?. And don't seems to much code added, so for me this doesn't break PAYG. As I said before I think we should not be purist to the limit. Maybe I'd need to experiment a bit with all this stuff to end understanding and assimilate. What do think others? any problem to add this notification system? thanks -- Carlos Rovira http://about.me/carlosrovira
