Re: [whatwg/streams] ReadableStream constructor: standard text and reference implementation doesn't match (#917)

> If we have implementations that already know that they'd go this route, then we might as well admit that we're leaving the order implementation-defined :/

I just looked at WebKit's implementation, and it's using JS with no destructuring assignment. They use IDL together with the JavaScript somehow, but they just use `any` for the options arguments rather than dictionaries. So I'm counting them in the "don't care" camp. I have a vague recollection that Edge had some difficulties because they were using WebIDL in their implementation, but I can't remember where I heard that and I don't know anyone I could ask to get an opinion.

So, I'm going to conclude that there's no significant implementer restrictions on ordering, and we can do what makes sense for the standard.

Since the TransformStream constructor has two strategy arguments and so can't use destructuring assignment for them, I'm going to say that for consistency none of the constructors should use destructuring assignment.

Here's the current order of lookups/validations for the ReadableStream constructor:

1. Lookup _type_
2. Lookup _size_
3. Lookup _highWaterMark_
4. ToString(_type_)
5. toNumber and validate _highWaterMark_
6. Validate _size_
7. Lookup _pull_
8. Validate _pull_
9. Lookup _cancel_
10. Validate _cancel_
11. Lookup _start_
12. Validate _start_

The reason the lookups for size and highWaterMark are separated from their validations is so they can be factored out of the "if" statement based on the type. So there's actually not much I want to change here, except I'd like to validate _size_ before _highWaterMark_, because that's what WritableStream and TransformStream do.

-- 
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/917#issuecomment-378938885

Received on Thursday, 5 April 2018 13:38:47 UTC