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

* Tab Atkins Jr. wrote:
>However, events aren't well-suited for this either, as you can't tell
>what the "current" state of loading is at the time you register
>events.  Plus, while this exact case won't ever have errors, other
>similar cases may, so they'd need to add an error event too.

You are saying that you want to inspect the state at the level you call
`addEventListener` on, but it sounds like you want to inspect the state
in the event listener, which you assume would not work because there is
initially no state transition.

  var currentState = obj.state;
  obj.addEventListener('stateTransition', function(evt) {
    var newState = evt.newState;
  }, ...);

If you want `currentState` then "Futures" do not really help you in any
good way, you would rather want `obj.state` to simply exist. If you want
`newState` when it isn't "new", then that problem has come up a number
of times, and could trivially be addressed with events. There have been
some crude workarounds (make the event happen when a listener might need
"fresh" information), but there are also more elegant options available.

There is also the idea to have "Futures" for (certain?) events, see e.g.
http://lists.w3.org/Archives/Public/www-dom/2013JanMar/0203.html why I'm
interested in that.

>Basically, what I need is something like a ProgressFuture (after the
>"immediately ping with most recent value" change from my previous
>email), but which never completes.  That way I could just register a
>callback, get called in the next tick with the current value, and then
>called again every time the value is updated, forever.
>
>My immediate thoughts are that maybe this can be a ProgressFuture
>which is specified to never resolve.
>
>Another thought is to create a normal future (or a new type of future)
>that resolves multiple times.  This would let you use .then() as
>normal, rather than having to hook both .progress() and
>.then(null,...) if you want to listen for errors as well.  This might
>play better in the futures algebra, too, though it would need special
>handling - for the purpose of all other future combinators, it would
>act like it was initially unresolved and resolves the next time it
>receives a "progress update".

Both options are fairly incompatible with the way I look at "Futures".
For instance, in neither case does the "Future" represent anything, in
the first case it's outright nothing, and in the second case it would
not be bound to anything specific. You are basically trying to use them
as some kind of flow control or state maintenance syntax. That does not
seem entirely no-go, but I think this should come with a demonstration
of, say, that "Futures" are used this way in many other places, or per-
haps something that describes the theoretical foundations of these "Fu-
tures"; a formal proof, for instance, that these "Futures" are Monads
in the same way we would normally understand them to be Monads would be
helpful.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Friday, 12 April 2013 00:26:03 UTC