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

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:

```js
  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.