On Wed, Apr 3, 2013 at 11:45 AM, Jonas Sicking <jo...@sicking.cc> wrote:
> On Wed, Apr 3, 2013 at 10:43 AM, Tab Atkins Jr. <jackalm...@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: > Sure they do, they allow future extensibility. If we had used Futures for everything from the start the world would be quite different since we couldn't add any new information to the notifications. All the Future<boolean> stuff going on right now is just going to bite us later when we want to add more features to some notification. This is fine in a JS app, just refactor the app, this isn't nice on the web when we can never change an API once it's shipped. > > 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. > > When I first saw the Future stuff go by it seemed it was trying to address one off notifications, but now we're busy shoving it down the throat of every API, even ones that are sending repeated notifications. For example requestAnimationFrame _could_ be a Future<int> since it's only called once, but now we want to pass a bunch of information into from the compositor but can't since there's no extensibility mechanism. What's the long term evolution plan for all this? How do we extend the APIs in the future since we don't have an Event object to add properties to? - E
