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

2015-03-11 16:24 GMT+01:00 Domenic Denicola <notifications@github.com>:
>
> 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.

I guess I have a slight preference for all or none here, but I will
not push hard either way.
Synchronous error signaling is already possible after all.
Adding a test would be nice.

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

I was referring to browser implementations that may need to create JS
function wrappers around native code. If we were to create those just
for start(), the wrappers handling would be delegated to the JS
engine, which is a bit simpler and a bit more optimal.

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

By native sources, I was referring to stream producers like fetch.
In that case, the interface between stream and source will be closer
to pull() than to pull (enqueue, close). But anyway, this is a minor
point.


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