Re: [futures] Making ProgressFuture immediate

> 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
>
>