- From: Jake Verbaten <raynos2@gmail.com>
- Date: Thu, 11 Apr 2013 18:37:50 -0700
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: "www-dom@w3.org" <www-dom@w3.org>
- Message-ID: <CAMCMjp0axgssCaTxJ0va7AdPgWxs39tBYNS2V7Wsxn8U-wArnA@mail.gmail.com>
> That prevents you from initializing the progress UI with the "current" progress The abstraction your looking for is a representation of a value over time. I don't think a Future is a good abstraction to model this. There is a ton of prior art on representing values over time in FRP in terms of signals ( http://en.wikipedia.org/wiki/Functional_reactive_programming ) Rather then overloading a `Future` which is a representation of either a concrete value or a failure which will be known at some point in the future we may want to consider representing the progress use-case as a changing value. For JavaScript implementations, RxJS calls this an "Observable" ( https://github.com/Reactive-Extensions/RxJS/wiki/Observable ) and bacon.js calls this a Property ( https://github.com/raimohanska/bacon.js#property ). Dominictarr also has a minimal 200 line implementation of this idea ( https://github.com/dominictarr/observable ) The reason I mention FRP & signals is that it's the only abstraction I know of that's kind of similar to events & futures but actively capture and models the notion of "current state" in a period of time. I've personally found having an abstraction that's like an event but also captures current state is a powerful tool for asynchronous programming. On Thu, Apr 11, 2013 at 4:05 PM, Tab Atkins Jr. <jackalmage@gmail.com>wrote: > A common use-case for ProgressFuture will be using the progress values > to drive progress UI for the user. However, the current design is > flawed for this use-case. Right now, the progress callback is only > called when the future's resolver posts a new progress update. That > prevents you from initializing the progress UI with the "current" > progress - you have to wait until the next heartbeat occurs, which may > be an arbitrary amount of time in the future. This is precisely the > sort of "just missed it" race condition that futures were designed to > avoid. > > I propose that we change it so that, if at least one progress update > has already been made and the future isn't yet resolved, the progress > callback is immediately (next tick) called with the most recent > progress value. That way the progress updates also act kinda like > futures in general, which is nice. > > ~TJ > >
Received on Friday, 12 April 2013 01:38:18 UTC