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

>
> I'm loathe to make the constructor design inconsistent between the three
> classes. On the other hand, it seems like a low-risk change to cache all
> the methods on all the constructors, so if this is important, I think we
> should do that.
>
That seems fine to me, too.

> It's a bit weird from a JS perspective IMO. If we're treating these things
> as methods, the usual syntax for method calling is foo.bar(), not
> previouslySavedBar.call(foo). But few people will notice.
>
It should be clear in the spec, perhaps including in examples, for sure.
Other than that, I think the few people who'd even notice would just apply
one of the trivial workarounds and move on. There really isn't a realistic
way for them to be affected without noticing, I think.

> We don't want to go back to just treating them as functions, as that
> breaks cases like https://streams.spec.whatwg.org/#example-both.
>
Fully agreed, calling them with the original object as the receiver makes
sense.

> It would bloat the size of each object a decent bit, e.g.
> ReadableStreamDefaultController would end up with three more internal
> slots to store start, pull, and cancel.
>
We'd only need to store `pull` and `cancel`, right? `start` is invoked in
the constructor and not needed after that, IINM. I agree that this is
unfortunate, but think it's worth it for the added optimization potential.


-- 
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#issuecomment-285526338