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

On Thu, Apr 11, 2013 at 5:25 PM, Bjoern Hoehrmann <derhoermi@gmx.net> wrote:
> * 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.

Right, Futures as written are not appropriate.  I'm not particularly
looking for a Future to solve this, but rather looking for a specified
and well-known callback pattern for this, so that specs can use the
One True Pattern when they need to do this, rather than doing lots of
ad-hoc things.

Today's specs solve this problem in lots of different ways, usually by
using a combination of arbitrarily-named events for state transitions
and arbitrarily-named attributes storing the current state.  It's the
"arbitrarily-named" part that I'd like to solve.

~TJ

Received on Friday, 12 April 2013 01:36:46 UTC