- From: Adam Rice <notifications@github.com>
- Date: Wed, 05 Dec 2018 00:10:34 -0800
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3ctag/design-reviews/issues/282/444395747@github.com>
> Given what you've shown above re: identity streams, what's the argument for preventing subclassing? A `TransformStreamDefaultController` and a `TransformStream` are mutually associated for the lifetime of the `TransformStream`. `TransformStreamDefaultController` objects are only created during construction of `TransformStream` objects. A `TransformStreamDefaultController` that was not associated with a `TransformStream` would be useless. @domenic wrote more about the principles of the design in [The Revealing Constructor Pattern](https://blog.domenic.me/the-revealing-constructor-pattern/). Suppose hypothetically that we permitted constructing a "detached" `TransformStreamDefaultController`. We could add a way to pass it into the `TransformStream` constructor to have it "attached" to the newly-constructed `TransformStream`. What extra capabilities would this afford the web developer? They could subclass `TransformStreamDefaultController` and override `enqueue()`, `error()` and `terminate()` methods. However, they are the only person who will be calling `enqueue()`, `error()` and `terminate()`. They control all the call sites, so changing the call sites would be a much simpler way to accomplish the same thing. If they didn't want to change the call sites, they could wrap the controller object passed to their `start()` method, or modify the controller object directly. So preventing subclassing reduces complexity with no loss of generality. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3ctag/design-reviews/issues/282#issuecomment-444395747
Received on Wednesday, 5 December 2018 08:10:56 UTC