- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Wed, 3 Apr 2013 12:40:40 -0700
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: public-webapps <public-webapps@w3.org>
On Wed, Apr 3, 2013 at 11:45 AM, Jonas Sicking <jonas@sicking.cc> wrote: > On Wed, Apr 3, 2013 at 10:43 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote: >> The ProgressFuture strawman at >> <https://github.com/slightlyoff/DOMFuture/blob/master/ProgressFuture.idl> >> augments a future with an analog of progress events. >> >> Why isn't this just using actual events? That is, make ProgressFuture >> an eventTarget as well, which fires progress events. >> >> I'm fine with the existing API existing as it is, where convenience >> APIs are provided both for firing (a 'progress' method on the >> resolver) and listening to (a 'progress' method on the future) >> progress events. It just seems weird to implement events without them >> being actual Events. > > Define "seems weird". > > Using Events as a way to do callbacks has many advantages when using > them on Nodes. However they provide much less value when used on > "standalone objects" like XMLHttpRequest and a Future object. With > using a callback it means that we can both provide a more convenient > registration syntax: > > doSomeAsyncThing(...).progress(showProgress).then(processResult, handleError); > > Additionally the actual progress handler gets a cleaner API. Instead > of having an Event object that has a bunch of irrelevant stuff on it, > like .stopPropagation(), .preventDefault() and .bubbling, the caller > just gets the relevant data. > > We've come to use Events as a general callback mechanism. However > that's never been where they shine. Using Events here just causes more > edge cases to define for us, likely more code for implementations, and > more and less convenient API for authors. I'm fine if this kind of break is *intentional*. It wasn't clear to me that it was - it just looked like the API was reinventing events in a custom way, just like so many APIs reinvent futures in a custom way right now. If that's the case, it should be documented somewhere that, if you're attaching something event-like (where 0+ listeners subscribe to 0+ notifications) to a future, but don't need the full DOM event system, you should do it in this particular way. ~TJ
Received on Wednesday, 3 April 2013 19:41:27 UTC