Re: [futures] Persistent/Repeated Future that doesn't resolve

On Thu, Apr 11, 2013 at 5:05 PM, Domenic Denicola
<domenic@domenicdenicola.com> wrote:
> I think this isn't a great use case for promises. Indeed, I don't think progress in general is a good use case for promises: it doesn't fit the sync/async function call parallel that they try to model.

Progress seems to be a necessary case for promises, unless you want to
break consistency for what is otherwise a trivial addition - there are
plenty of actions which definitely complete at some point, and which
you want to respond to the completion of in the promises fashion (if
completed, notify me immediately, otherwise notify me when it
completes), but which also can usefully hand out progress information.
 It seems like "partial" completion is very near to "completion"
thematically, and so the two should be addressed in a similar/close
fashion if possible.

> Rather, what you're looking for is probably something more like an event stream, from functional reactive programming. The more interesting implementations of these that I have seen include [RxJS][] and [Dart's stream API][]. There is some hope of getting something like this in the DOM, and having use cases like this are very helpful toward that work, but I don't think any ideas have gelled yet into something usable. It's very tricky to get right.

Hm, Streams *might* work.  However, it looks like they usually still
fall prey to the "can only see the *next* update after subscribing"
problem.  If we had something that would inform you of the
most-recently-published value as well when you subscribed, it would
probably work better.  If I'm reading correctly, they also
automatically feed you the entire history of the stream, while the
use-cases I'm thinking of just need to know the "current" state and
future states.

I'm thinking something like this:

interface EventStream {
  EventStream attribute listen(valueCB, errorCB);
  Future next(valueCB, errorCB);
}

In listen(), valueCB is called every time a new value is pushed, and
immediately (next tick) with the most recently pushed value if at
least one value as already been pushed.  errorCB is called when the
stream's resolver rejects, which also kills the stream.  It returns
the same stream, for chaining.

next() returns a Future for the next value to be pushed, constructed
with valueCB and errorCB.

~TJ

Received on Friday, 12 April 2013 01:32:12 UTC