bzbarsky at MIT.EDU
Thu Jan 30 14:55:32 PST 2014
On 1/30/14 11:52 AM, Forrest L Norvell wrote:
> I agree with this entirely, with the caveat that "partially obscured"
> and even "boilerplate" are in this case subjective factors.
Absolutely. In fact, it sounds like we agree on most of this stuff in
> It's interesting that you raise this issue, because all of the aspects
> involving asynchronicity and callbacks in Domenic's spec do so in the
> context of ES promises, and unless I'm missing something
Hmm... It's hard to tell. I'm looking at things like [[callPull]](),
When/if this.[[startedPromise]] is fulfilled, call
this.[[onPull]](this.[[push]], this.[[close]], this.[[error]]).
I don't think this is explicitly defining what the script settings stack
looks like when the [[onPull]] function is called, because the "When/if
this.[[startedPromise]] is fulfilled" wording doesn't tell me exactly
how this interacts with the promise specification and its manipulation
of that stack. Is this supposed to have equivalent behavior to doing:
or something else? If this is supposed to be like a then() call, then I
agree that promises would completely define the behavior here. But if
this is just saying that at some point after the promise is fulfilled
the [[onPull]] needs to be called, then the behavior is not defined by
Unfortunately, the promise specification doesn't handle incumbent/entry
settings objects either, so the behavior is undefined no matter what.
:( It needs to.
More information about the es-discuss