W3C home > Mailing lists > Public > www-dom@w3.org > April to June 2013

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 11 Apr 2013 18:36:00 -0700
Message-ID: <CAAWBYDBFTaanVcuimju5VTRm-p6A+McOMetZOU8g3=3Oh=qp1Q@mail.gmail.com>
To: Bjoern Hoehrmann <derhoermi@gmx.net>
Cc: "www-dom@w3.org" <www-dom@w3.org>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:20 UTC