- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 3 Apr 2013 11:45:10 -0700
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: public-webapps <public-webapps@w3.org>
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. / Jonas
Received on Wednesday, 3 April 2013 18:46:11 UTC