[whatwg/streams] How much latitude should implementations have in looking up transformer.transform()? (#691)

Pull request #689 verifies that transformer.transform is looked up in exactly the same way as the reference implementation. But this puts pretty severe restrictions on possible optimisations. For example, `new TransformStream()` can be optimised to skip Javascript altogether, but `new TransformStream({})` cannot. Here are some use cases for a TransformStream with no transform() method:

1. A TransformStream which adds extra buffering to a pipe.
2. A TransformStream which adds a header and/or footer to the stream but does nothing else.

I see two ways we could permit optimisation here:
1. Make the standard ambiguous about when (and how?) the "transform" attribute of transformer is looked up.
2. Change the reference implementation (and hence the standard) to look up the "transform" attribute in the constructor only.

I think for developers 2. is better than 1. because it will at least be consistent between implementations even if it's different from the way sources and sinks work.

The semantics we provide for sources and sinks are that we treat them exactly like an object, including expected Javascript behaviours like dynamically changing prototypes.

My feeling is that complying with this expectation is important, even though only a tiny proportion of developers may take advantage of the flexibility. On the other hand, falling off a performance cliff because you wrote `new TransformStream({})` instead of `new TransformStream()` is suboptimal. Making identity transforms always be slower just to avoid surprising performance behaviour would also be bad.

Thoughts?

-- 
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/issues/691