King and paige (page), king can only talk and listen to one paige at a time.
On Dec 7, 6:21 pm, Aaron Newton <[email protected]> wrote: > JavaScript is a single-threaded environment. There's no such thing > as asynchronous invokation. If there are *N *functions on a stack that need > executing, they'll all be executed one at a time. Even if you set a timeout > on each one of 0ms, as soon as that function is invoked nothing else is > going on. > > On Tue, Dec 7, 2010 at 6:08 PM, Sean McArthur <[email protected]>wrote: > > > See herehttp://jsfiddle.net/seanmonstar/zT2ta/ > > > <http://jsfiddle.net/seanmonstar/zT2ta/>Native handlers are executed in > > the order they are added. If they weren't, you couldn't modify a form > > onSubmit, since the submit would finish before you modified any inputs. > > > As for Class events, some are used to as "before" events. > > > this.fireEvent('beforeConnect'); > > > This way, someone could tie in and make sure something happens *before* the > > connect code runs. However, as the Class writer, you do have the ability of > > forcing every event handler listening to your Class fire *after* all your > > code runs. > > > this.fireEvent('event', args, 1); > > > On Tue, Dec 7, 2010 at 3:02 PM, אריה גלזר <[email protected]> wrote: > > >> And anyway - the rest of my case still stands - events being an interface > >> for class communication, they shouldn't be affected by other classes that > >> may or may not be attaching events as well. > > >> I am curious though - are Node event asynchronous? > > >> On Wed, Dec 8, 2010 at 12:57 AM, אריה גלזר <[email protected]>wrote: > > >>> But aren't the various functions fired async? > > >>> On Wed, Dec 8, 2010 at 12:51 AM, Sean McArthur > >>> <[email protected]>wrote: > > >>>> DOM Events aren't asynchronous. You can stop the bubbling on the event, > >>>> or prevent default, or even just return false in a native event handler. > >>>> That wouldn't be possible if the handlers executed asynchronously. > > >>>> On Tue, Dec 7, 2010 at 2:47 PM, אריה גלזר <[email protected]>wrote: > > >>>>> This is another one of those "I know it won't be implemented but think > >>>>> it should": > > >>>>> Native JS events are async by nature, and it's one of the things that > >>>>> make them that useful. It's also how we're used to using them. But Class > >>>>> events are all synchronous. One of the important parts of events is that > >>>>> they allow us to encapsulate behavior - it's a very clean way for one > >>>>> class > >>>>> to use another. It's essentially an observer pattern, and it's a part of > >>>>> what makes moo that much more useful and powerful. > >>>>> The reason I find this important is that making event calls synchronous > >>>>> is creating a lot of unmeasurable, untestable noise. What if by chance a > >>>>> heavy function done by another class is called before mine? > > >>>>> The only issue I can see here is that this might be a breaking change > >>>>> if someone is using Class events to modify it's behavior, but then we > >>>>> can > >>>>> add a fireEvent([...],async) flag or something. > >>>>> I'm also posting a ticket for this, but I think it's only worth the > >>>>> while if it's discussed (and I feel weird opening a discussion on the > >>>>> lighthouse). > > >>>>> as a side note - it seems that code change is actually very very small. > > >>>>> thoughts? > > >>>>> -- > >>>>> Arieh Glazer > >>>>> אריה גלזר > >>>>> 052-5348-561 > >>>>>http://www.arieh.co.il > >>>>>http://www.link-wd.co.il > > >>> -- > >>> Arieh Glazer > >>> אריה גלזר > >>> 052-5348-561 > >>>http://www.arieh.co.il > >>>http://www.link-wd.co.il > > >> -- > >> Arieh Glazer > >> אריה גלזר > >> 052-5348-561 > >>http://www.arieh.co.il > >>http://www.link-wd.co.il
