Re: [streams] Do we need to pass enqueue and close as parameters to UnderlyingSource.pull? (#292)

> Is it for web developer conveniency?

Yes, this is largely for convenience. Otherwise the code for an underlying source becomes fairly awkward, I think. See e.g. https://streams.spec.whatwg.org/#example-rs-pull; it would become much more annoying to write.

> If so, why not also passing the error function to pull?

The thinking behind the current design is that you can just reject the promise returned from pull to signal errors there. (In this way error and enqueue/close are quite different, since there is no way of using the promise to signal enqueue/close.) However, it would not hurt very much to also pass the error function, and it would allow synchronous signaling of errors in addition to asynchronous signaling. Perhaps we should do that.

> Not passing them to pull would remove the need for the ReadableStream to keep a reference to these functions and let the JS engine collect these methods as needed.

Not quite. We use `this@[[error]](e)` several places in the spec, so it would need to stay around. And, if the underlying source `start()` captures `close` in some closure, like e.g. https://streams.spec.whatwg.org/#example-rs-push-no-backpressure does, then we won't be able to collect `close` at all. In fact we will only ever be able to collect `close` if the stream plans to never close itself. Which should not be normal.

> This may also be more inline with how native sources pulling will be implemented.

Hmm, can you explain what you mean by this? One example of native pull sources is https://streams.spec.whatwg.org/#example-rs-pull, which doesn't seem to be in line with that.

---
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/streams/issues/292#issuecomment-78285064