Re: [w3ctag/design-reviews] TextEncoderStream and TextDecoderStream (#282)

> 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