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
general. ;)
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]](),
which say:
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:
this.[[startedPromise]].then(
this.[[onPull]].bind(undefined, this.[[push]],
this.[[close]], this.[[error]]))
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
Promises.
Unfortunately, the promise specification doesn't handle incumbent/entry
settings objects either, so the behavior is undefined no matter what.
:( It needs to.
-Boris
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
