- From: Domenic Denicola <notifications@github.com>
- Date: Thu, 25 Mar 2021 15:30:53 -0700
- To: whatwg/streams <streams@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/streams/pull/1110/c807627310@github.com>
> CompressionStreams are not broken: the ds variable comes from the value of this when transformAlgorithm is created. TextEncoderStream and TextDecoderStream do the same thing. I guess you're saying, they're a bit broken, but they'd be fixed if you replaced _ds_ with "this"? Right now [the DecompressionStream constructor](https://wicg.github.io/compression/#dom-decompressionstream-decompressionstream) references an undefined _ds_ variable. I agree that seems to work, but it's only because the somewhat-unusual choice we've made (#1074) of having different types of transform streams be wrappers instead of subclasses. That means there's an easy way to indirectly capture the stream by passing "this" and then later referencing "this's transform" (but only after "this's transform" has been set up). Taking a step back, I guess we have the following sorts of consumers: - Subclassers (of ReadableStream and WritableStream) - They need to use "set up" for sure - Wrappers (of TransformStream) - They can use create + the this's transform trick - Wrappers (of ReadableStream and WritableStream), such as fetch `Response` or Web RTC Encoded Transform (insertable streams) - They can use create in a natural way *only if* they enqueue from outside the pullAlgorithm, like fetch does. - Or they could use a custom level of indirection, such as: "Let stream be null. Let pullAlgorithm be the following steps: ... enqueue chunk into stream. Set stream to the result of creating a ReadableStream given pullAlgorithm." - This is even trickier if you want to define your pullAlgorithm to call a separate set of steps. Then you need a mutable structure, e.g. "Let holder be an empty list. Let pullAlgorithm be the following steps: perform the pull algorithm given holder. Set holder[0] to the result of creating a ReableStream given pullAlgorithm. The pull algorithm, given a list holder, is: ... enqueue chunk in holder[0]." - Otherwise they have to use Web IDL new + set up. I don't like this inconsistent landscape, which is my motivation for moving everything to "set up". WDYT? -- 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/pull/1110#issuecomment-807627310
Received on Thursday, 25 March 2021 22:31:06 UTC