Need to adjust IDL to make overload definitions distinguishable?

[tidoust]

#20 takes care of merging overloaded definitions to meet one of the overloading requirements defined in Web IDL. Web IDL also requires that overload definitions be distinguishable.

The Autoplay Policy defines the following IDL:

callback HTMLMediaElementConstructor = HTMLMediaElement ();
callback AudioContextConstructor = AudioContext ();

[Exposed=Window]
partial interface Navigator {
  AutoplayPolicy getAutoplayPolicy(HTMLMediaElementConstructor mediaCtor);
  AutoplayPolicy getAutoplayPolicy(AudioContextConstructor audioCtor);
};

If I'm reading Web IDL correctly, two callback functions are not distinguishable (see the matrix in the Web IDL spec).

This can probaby be fixed with a union type instead:

callback HTMLMediaElementOrAudioContextConstructor = (HTMLMediaElement or AudioContext) ();

[Exposed=Window]
partial interface Navigator {
  AutoplayPolicy getAutoplayPolicy(HTMLMediaElementOrAudioContextConstructor ctor);
};

The Web IDL validator does not check these requirements, so I'm not 100% sure that the above analysis is correct. It may be worth checking with Web IDL experts. Cc @w3c/webidl-design for possible confirmation.

[domenic]

The deeper issue here is there's no way to distinguish these two types, so such an overload---or union---is meaningless. JavaScript functions passed to your method don't signal their return value in some way spec code can distinguish. You can't know what a JavaScript function will return, until you call it!

Probably instead you want the callback to return object, and then you can do tests in prose accounting for the three cases of interest: the result of calling the callback implements HTMLMediaElement, the result implements AudioContext, or neither of those things are true.

[tidoust]

Hmm, that means that browsers would need to call the constructor themselves to check the return type. That does not sound like very good design (arbitrary constructors may have side effects).

For context, the current design originates from #15 (comment)

@alastor0325, this may suggest that the spec needs to consider a different approach. Perhaps with an enum? Something like:

enum AutoplayPolicyMediaType { "audio", "video", "media" };

[Exposed=Window]
partial interface Navigator {
  AutoplayPolicy getAutoplayPolicy(AutoplayPolicyMediaType type);
};