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 here http://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 >> >> >
