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

> I guess the theoretical problem that remains is if you have something that wants to accept either a transform stream or something else and something else happens to have similarly named properties.

In practice using the APIs I find I don't pass around TransformStreams. I either supply them directly to `pipeThrough()`, or I split them into the `readable` and `writable` and do separate things with each part. `pipeThrough()` is specified to check that `readable` and `writable` properties exist, but I expect that to be the exception.

> If we go with duck typing, why does this use string properties rather than symbols (as iterators do)?

Iterators do use string properties. An iterator is an object that has a `next()` method. It returns objects with properties `value` and `done`.

_Iterables_ use symbol properties. I assume this is because they have to avoid name collisions and problems with enumeration.

I think a transform stream is more like an iterator than an iterable in this respect.

> It seems like this approach would also require pipeThrough() to be taught about all possible objects that are actually known to be streams for optimizations? (Implementation detail, but falls out of this kind of design.)

Implementations are not prevented from sharing optimisation infrastructure because we don't inherit from TransformStream. Because `pipeThrough()` just delegates to `pipeTo()`, the pipe optimisation strategy I expect is to expose an internal API on WritableStream that says "here's the kinds of pipe optimisation I know how to participate in".

On the other hand, inheritance can get in the way of implementations that want to optimise by bypassing TransformStream machinery, as @domenic alluded to.

-- 
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-397299063