WebIDL method ordering dependency?

[Raymond Toy]

The WebAudio spec is proposing to add a dictionary the the decodeAudioData dictionary.  The IDL defintionis are basically going to be

Promise<AudioBuffer> decodeAudioData(ArrayBuffer audioData, optional AudioBufferCallback successCallback, optional AudioBufferCallback errorCallback);

Promise<AudioBuffer> decodeAudioData(ArrayBuffer audioData, DecodeAudioDataOptions options);

The first is the existing method, and the second is the new method.

I implemented this in blink like so:

    [RaisesException, MeasureAs=AudioContextDecodeAudioData, CallWith=ScriptState] Promise<AudioBuffer> decodeAudioData(ArrayBuffer audioData, optional AudioBufferCallback successCallback, optional AudioBufferCallback errorCallback);

    [RaisesException, MeasureAs=AudioContextDecodeAudioData, CallWith=ScriptState] Promise<AudioBuffer> decodeAudioData(ArrayBuffer audioData, DecodeAudioDataOptions options);

This doesn't work.  Whenever I try decodeAudioData(<buffer>, { disableResampling: true}), I get an error that the second arg isn't a function.

However, when I edit the idl file and reverse the order of the methods, everything works.

Is this expected?  I'm not 100% sure, but I think the idl compiler worked before, as shown in https://codereview.chromium.org/2085353008, patch 2 which was uploaded 3 weeks ago.

[Joshua Bell]

On Fri, Jul 22, 2016 at 2:00 PM, 'Raymond Toy' via blink-dev <blin...@chromium.org> wrote:

The WebAudio spec is proposing to add a dictionary the the decodeAudioData dictionary.  The IDL defintionis are basically going to be

Promise<AudioBuffer> decodeAudioData(ArrayBuffer audioData, optional AudioBufferCallback successCallback, optional AudioBufferCallback errorCallback);

Promise<AudioBuffer> decodeAudioData(ArrayBuffer audioData, DecodeAudioDataOptions options);

This IDL seems problematic. Trailing dictionaries w/o required members must be optional (http://heycam.github.io/webidl/#idl-operations) Unless DecodeAudioDataOptions has a required member (and it doesn't look like it per https://codereview.chromium.org/2085353008) then the second overload needs 'optional'. And then it's ambiguous which overload is called if decodeAudioData() is called with one argument.

It could be respecified as:

Promise<AudioBuffer> decodeAudioData(ArrayBuffer audioData, AudioBufferCallback successCallback, optional AudioBufferCallback errorCallback);

Promise<AudioBuffer> decodeAudioData(ArrayBuffer audioData, optional DecodeAudioDataOptions options);

(Callback functions and dictionaries are not distinguishable - http://heycam.github.io/webidl/#idl-overloading - but AudioBufferCallback is a callback interface so I think that's okay...?)

 

The first is the existing method, and the second is the new method.

I implemented this in blink like so:

    [RaisesException, MeasureAs=AudioContextDecodeAudioData, CallWith=ScriptState] Promise<AudioBuffer> decodeAudioData(ArrayBuffer audioData, optional AudioBufferCallback successCallback, optional AudioBufferCallback errorCallback);

    [RaisesException, MeasureAs=AudioContextDecodeAudioData, CallWith=ScriptState] Promise<AudioBuffer> decodeAudioData(ArrayBuffer audioData, DecodeAudioDataOptions options);

This doesn't work.  Whenever I try decodeAudioData(<buffer>, { disableResampling: true}), I get an error that the second arg isn't a function.

However, when I edit the idl file and reverse the order of the methods, everything works.

Is this expected?  I'm not 100% sure, but I think the idl compiler worked before, as shown in https://codereview.chromium.org/2085353008, patch 2 which was uploaded 3 weeks ago.

Overloading is the most complex part of the WebIDL spec and I don't know how close Blink's implementation is to the spec at this point - it's entirely possible you've found a bug. IIRC, there are also Blink IDLs that violate Web IDL and ordering is important, so I'm not surprised.

(Sorry that last bit isn't helpful. The bindings team will doubtless have a definitive answer.)

[Boris Zbarsky]

On 7/22/16 6:19 PM, Joshua Bell wrote:
> This IDL seems problematic.

Indeed. A spec-compliant IDL parser should error out on it...

> (Callback functions and dictionaries are not distinguishable -
> http://heycam.github.io/webidl/#idl-overloading

But note https://www.w3.org/Bugs/Public/show_bug.cgi?id=21640 -- the
desire to distinguish them has come up before. Technically this is not
that hard to do, I think: we could declare that to distinguish between
the two you check whether the object is callable, and if it is decide
it's a callback, not a dictionary.

It might be worth revisiting that decision.

>- but
> AudioBufferCallback is a callback interface so I think that's okay...?)

That would be worse, actually: a callback interface _can_ just be any
random object, just like a dictionary. So there really isn't any way to
distinguish between the two.

-Boris

[Elliott Sprehn]

+platform-architecture-dev

[Kentaro Hara]

+bashi +yukishiino

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to platform-architect...@chromium.org.
To post to this group, send email to platform-arc...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CAO9Q3i%2B1Wu7VTbNVJB1xTNQcuCKQwM-uNjTgLWrEN3q_Cc7Oaw%40mail.gmail.com.

--

Kentaro Hara, Tokyo, Japan

[Yuki Shiino]

Nothing to add.

callback interface vs dictionary is not distinguishable, and

callback function vs dictionary is not distinguishable, either.

It's also true that Blink doesn't support callback interface/function well.  We need several fixes in this area.  See also https://crbug.com/629068 , which might be related.

Cheers,

Yuki Shiino

[Raymond Toy]

Thanks for everyone's comments.

In summary, I take it that this pattern won't work with the current IDL specification (unless https://www.w3.org/Bugs/Public/show_bug.cgi?id=21640 is revisited).

WebAudio needs to figure out a different way of adding the dictionary support.