Re: [whatwg/streams] Setting Object.prototype.then permits interfering with pipeTo() internals (#933)

> But we could alternatively add warnings to the standard text for ReadableStreamDefaultReaderRead() and other operations which appear to resolve to an iterator, but which can in fact resolve to undefined or anything else. And standards such as fetch that call those operations would need to write tests for those cases.

In an ideal world, I think we'd decouple the public API (which returns iter-result objects) from the spec-facing API.

>From this perspective, maybe it's as simple as changing the internal data structure from JS objects to records, and only reifying the records into JS objects once we expose to web developers? Hmm, I guess not so simple, because we use promises so heavily as our interface to other specifications, and a promise for a record doesn't make much sense :(. https://github.com/whatwg/infra/issues/181 again.

I guess a halfway solution is to change everything to use null-prototype iter-result objects, but have read() then re-allocate to a non-null object. And of course include a long explanatory note explaining what is going on and why things work this way.

> Simple sketch:
> ...
>
> This is already more prescriptive than the definition of pipeTo(). I think the biggest difference is that it removes the flexibility to run an arbitrary number of microtasks between enqueue() and write(). I think it makes the existing reference implementation non-conformant.

This doesn't sound too bad! I'd see two alternatives:

- Encourage this synchronous data-shuffling. Update the reference implementation to ape your spec text. Write tests to enforce it.
- Just be loose. Allow the implementation to insert its own implementation-defined delay before writing in the pipeTo() algorithm.

In my mind, running an arbitrary number of microtasks is not a useful bit of flexibility. Useful flexibility would allow the UA arbitrary delay (e.g. it could queue a task, and choose a task queue that might get deprioritized vs. user input handling tasks). So the above two directions make sense to me.

I recognize this only solves our pipeTo() problem, and not the issue of fetch() having to deal with bad chunks. So maybe we shouldn't bother, if we want to solve the larger problem anyway. But it's still kind of nice.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/streams/issues/933#issuecomment-400828113