Re: [whatwg/encoding] Add Streams support (#72)

> I'm not concerned about the example in #72 (comment), because the output is the same regardless of who reads it.

Sure, but that's only because the example uses an identity transform stream. If it used a transform stream that did the same type of text decoding, you'd have the same problem, with `what` being '💙' vs. '\ufffd'.

> To solve this issue, chunks which are in the TransformStream's writable's queue would need to be read by TextDecoder's decode() method. This requires all the machinery of a sync API to implement.

It really comes down to whether you consider the TransformStream and the TextDecoder to be the same object or not. If you consider them the same object, which this proposal does, then it's "just" a matter of looking at your own internal queue, which seems fairly kosher.

I recognize it's a bit different, since actually the WritableStream/ReadableStream objects are separate from the TextDecoder object. But I'd argue that to the user, by reusing the same object, you've created an expectation that they share the same internal queues.

If we don't think reusing the same internal queues is feasible, due to e.g. not wanting to add an internal sync access API, then that pushes me back toward having separate objects, e.g. `TextDecoder.stream()` vending a vanilla `TransformStream` with its own queues, instead of making `TextDecoder` into hybrid object.

Stated another way, it seems weird to expose `readable` and `writable` properties on a `TextDecoder` if they are just forwarding to an internal `TransformStream` that is totally disconnected from the rest of the goings-on of the `TextDecoder` object.

(Also, re: @annevk's https://github.com/whatwg/encoding/issues/72#issuecomment-251314342: `stream()` ends up creating an object which you can definitely create through a constructor. It's basically a shortcut for `new TransformStream({ ... transformer that uses a new TextDecoder ... })`.)

-- 
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/encoding/issues/72#issuecomment-367119832