Bug 159868 – [Streams API] Make ReadableStream properties not enumerable

• Status: RESOLVED
• Resolution: FIXED
• Component: WebCore Misc.

[youenn fablet]

According wpt tests, ReadableStream et al interfaces are not perfectly aligned with the test/spec

[youenn fablet]

Created attachment 283886 [details]
Patch

[youenn fablet]

Created attachment 283887 [details]
Patch

[Darin Adler]

Comment on attachment 283887 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=283887&action=review

It’s surprising none of these are enumerable. Is this some kind of new trend in modern DOM APIs?

> Source/WebCore/Modules/streams/ReadableStream.js:108
> +    const options = (arguments.length > 1) ? arguments[1] : @undefined;

How is this different from:

    const options = arguments[1];

I don’t understand how the explicit length check has any effect.

[youenn fablet]

(In reply to comment #3)
> Comment on attachment 283887 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=283887&action=review
> 
> It’s surprising none of these are enumerable. Is this some kind of new trend
> in modern DOM APIs?

WebIDL is prescribing enumerable attributes/functions.
JavaScript APIs are mostly not-enumerable AFAIK. This is the case for promises and arrays for instance.
I also think that JS classes functions are not enumerable as well.


> > Source/WebCore/Modules/streams/ReadableStream.js:108
> > +    const options = (arguments.length > 1) ? arguments[1] : @undefined;
> 
> How is this different from:
> 
>     const options = arguments[1];
> 
> I don’t understand how the explicit length check has any effect.

Right, I removed the check.

[youenn fablet]

Created attachment 283983 [details]
Patch for landing

[WebKit Commit Bot]

Comment on attachment 283983 [details]
Patch for landing

Clearing flags on attachment: 283983

Committed r203402: <http://trac.webkit.org/changeset/203402>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.