Bug 146547

Summary: [Streams API] Remove ReadableStream custom constructor
Product: WebKit Reporter: youenn fablet <youennf>
Component: WebCore Misc.Assignee: youenn fablet <youennf>
Status: RESOLVED FIXED    
Severity: Normal CC: calvaris, commit-queue, darin
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch
none
Patch
none
Patch for landing
none
Patch for landing none

Description youenn fablet 2015-07-02 06:53:36 PDT
We should remove ReaableStream custom constructor
Comment 1 youenn fablet 2015-07-02 08:07:47 PDT
Created attachment 256009 [details]
Patch
Comment 2 youenn fablet 2015-07-03 01:46:36 PDT
Created attachment 256087 [details]
Patch
Comment 3 Darin Adler 2015-07-04 09:37:09 PDT
Comment on attachment 256087 [details]
Patch

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

> Source/WebCore/Modules/streams/ReadableStream.h:68
> +    static RefPtr<ReadableStream> create(JSC::ExecState&, JSC::JSValue, const Dictionary&);

Why does this return RefPtr instead of Ref? Can it return null?

> Source/WebCore/Modules/streams/ReadableStream.idl:32
> +    Constructor([Default=Undefined] optional any source, [Default=Undefined] optional Dictionary strategy),

Seems a bit wordy. Do we really need “Default=Undefined”? What is the default if it’s not undefined?

> Source/WebCore/bindings/js/ReadableJSStream.cpp:210
> +        throwVMError(&state, createDOMException(&state, TypeError));

Should probably be using throwVMTypeError, which should be overloaded as needed if it’s not already. And should have custom message, I think, like all the many other uses of throwVMTypeErrror.

> Source/WebCore/bindings/js/ReadableJSStream.cpp:220
> +                throwVMError(&state, createDOMException(&state, TypeError));

Should be using throwVMTypeError, as above. Also, should this check for infinity as well, or only NaN?

> Source/WebCore/bindings/js/ReadableJSStream.cpp:224
> +                throwVMError(&state, createDOMException(&state, RangeError));

Should make a helper function throwVMRangeError and use it.

> Source/WebCore/bindings/js/ReadableJSStream.cpp:233
> +                throwVMError(&state, createDOMException(&state, TypeError));

Should be using throwVMTypeError, as above.

> Source/WebCore/bindings/js/ReadableJSStream.h:55
>  class ReadableJSStream: public ReadableStream {

Missing space before colon. Also, I think this class should be marked "final".

> Source/WebCore/bindings/js/ReadableJSStream.h:57
> +    static RefPtr<ReadableStream> create(JSC::ExecState&, JSC::JSValue, const Dictionary&);

The return value should remain specific, ReadableJSStream rather than ReadableStream. The other call site can and should convert from one RefPtr to the other. If you’re worried about the exact code generated we could make sure we have the right kind of move constructor to make that work efficiently with no reference count manipulation.

> Source/WebCore/bindings/scripts/CodeGeneratorJS.pm:4692
> +            if ($codeGenerator->ExtendedAttributeContains($interface->extendedAttributes->{"ConstructorCallWith"}, "ScriptState")) {
> +                 push(@$outputArray, "    if (UNLIKELY(exec->hadException()))\n");
> +                 push(@$outputArray, "        return JSValue::encode(jsUndefined());\n");
> +            }

I am not sure it’s exactly right that “call with script state” automatically also means “raises exception”.
Comment 4 youenn fablet 2015-07-06 00:01:29 PDT
Comment on attachment 256087 [details]
Patch

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

>> Source/WebCore/Modules/streams/ReadableStream.h:68
>> +    static RefPtr<ReadableStream> create(JSC::ExecState&, JSC::JSValue, const Dictionary&);
> 
> Why does this return RefPtr instead of Ref? Can it return null?

It can return null in case an exception is thrown.

>> Source/WebCore/Modules/streams/ReadableStream.idl:32
>> +    Constructor([Default=Undefined] optional any source, [Default=Undefined] optional Dictionary strategy),
> 
> Seems a bit wordy. Do we really need “Default=Undefined”? What is the default if it’s not undefined?

We need to set the parameters as optional according the spec.

If not setting "Default=" explicitly, the binding generator should probably expect the DOM class to provide different methods.
But "optional without default" parameters are apparently not supported yet by the binding generator.

In our case, it is anyway more convenient to use "Default=..." so that the DOM class has just one constructor.

>> Source/WebCore/bindings/js/ReadableJSStream.cpp:210
>> +        throwVMError(&state, createDOMException(&state, TypeError));
> 
> Should probably be using throwVMTypeError, which should be overloaded as needed if it’s not already. And should have custom message, I think, like all the many other uses of throwVMTypeErrror.

OK

>> Source/WebCore/bindings/js/ReadableJSStream.h:55
>>  class ReadableJSStream: public ReadableStream {
> 
> Missing space before colon. Also, I think this class should be marked "final".

OK

>> Source/WebCore/bindings/js/ReadableJSStream.h:57
>> +    static RefPtr<ReadableStream> create(JSC::ExecState&, JSC::JSValue, const Dictionary&);
> 
> The return value should remain specific, ReadableJSStream rather than ReadableStream. The other call site can and should convert from one RefPtr to the other. If you’re worried about the exact code generated we could make sure we have the right kind of move constructor to make that work efficiently with no reference count manipulation.

OK.
I think to recall there is already a move constructor that could do that.

>> Source/WebCore/bindings/scripts/CodeGeneratorJS.pm:4692
>> +            }
> 
> I am not sure it’s exactly right that “call with script state” automatically also means “raises exception”.

The same check is done for methods called with ScriptState.
A specific keyword might be used to control this but I am not sure this is actually worth it.
Comment 5 youenn fablet 2015-07-06 01:15:27 PDT
Created attachment 256198 [details]
Patch for landing
Comment 6 youenn fablet 2015-07-06 01:18:32 PDT
Created attachment 256199 [details]
Patch for landing
Comment 7 WebKit Commit Bot 2015-07-06 02:03:31 PDT
Comment on attachment 256199 [details]
Patch for landing

Clearing flags on attachment: 256199

Committed r186323: <http://trac.webkit.org/changeset/186323>
Comment 8 WebKit Commit Bot 2015-07-06 02:03:36 PDT
All reviewed patches have been landed.  Closing bug.