Proposal: Allow WebIDL binding to expose parameters' types and enums' values

[eladalon1983]

Consider a Web app that calls a method exposed by the browser.

• What happens if one of the method's parameters is a dictionary? Dictionaries may be extended over time, and there are no good ways for Web apps to check whether the user agent supports recognizes new members.
• Similar problem with enum values.
• The problem is recursive, as parameters can themselves have sub-fields which are dictionaries.

@beaufortfrancois has raised the same issue in #1181. I suspect we might have both been prompted by the same recent discussion. François' proposal is interesting. I'd like to enrich the discussion by adding one more possible solution.

enum SomeEnum {
  "value0",
  "value1"
};

[ExposeParameters]  // <-- NEW!
void someFunction(SomeDictionary p0, int p1) {
  // ...
}

The new tag would then produce bindings that would allow something like this:

if (func.parameters.length >= 1 &&
    func.parameters[0].type == "enum" &&
    "someValue" in func.parameters[0].supportedValues) {
  ...    
}

Because this is recursive, it could even extend to real use-cases we're encountering in the field, which are somewhat complex:

const func = navigator.mediaDevices.getDisplayMedia;

// We know getDisplayMedia has >= 1 params, the first of which is a dictionary.
// No need to check. (But we could if we wanted to.)
const dict = func.parameters[0];

if ("selfBrowserSurface" in dict.members &&
    dict.members.selfBrowserSurface.type == "enum" &&
    "exclude" in dict.members.selfBrowserSurface.values) {
    // ...
}

We could also add an [ExposeParametersAs] tag to allow the exposure point of this metadata somewhere other than .parameters. But IMHO that doesn't matter much, as I am not familiar with any existing method exposed by the UA, where .parameters is taken. (Not to be confused with a parameter called "parameters", btw.)

Comparing the two proposals (the current one and #1181):

• The current proposal exposes method parameters; #1181 exposes members on interfaces. (The current proposal could be extended to interfaces.)
• The current proposal exposes recursively.
• The current proposal exposes field types.
• The current proposal exposes parameter types.
• The current proposal exposes enums' legal values.
• The current proposal is, sadly, more complex than #1181.

[eladalon1983]

(Clarification - function parameters are exposed as an array; dictionary members as a dictionary.)

[annevk]

I'm not sure why we should have many new issues to discuss this when we couldn't even get whatwg/webidl#107 resolved?

[eladalon1983]

I'm not sure why we should have many new issues to discuss this when we couldn't even get whatwg/webidl#107 resolved?

François and I have filed two new proposals for tackling this problem because we believed this would be the best way to facilitate renewed/continued discussion of the topic. If you think there's a better way, such as continuing on the original thread, please give us a specific proposal. We welcome meta-feedback on the best way to engage in this forum. But even more than that, we are eager to hear your thoughts on our specific proposals.

[annevk]

I have to say that I don't really see any new arguments presented.

Also, I recommend reading through https://whatwg.org/faq#adding-new-features. We don't typically start with proposals, unless there's already agreement that the problem is worth solving.

[eladalon1983]

We don't typically start with proposals, unless there's already agreement that the problem is worth solving.

It appears to me self-evident that the problem is worth our attention, based on some messages in the original thread. Naming two examples:

Rick Byers wrote:

... We continue to hear developers complain that they really don't consider that acceptable (complexity, obscurity, desire to reliably avoid exceptions, etc).

The above message represents multiple parties who might not be actively participating in the discussion, but whose interests we should keep in mind.

Then you (@annevk) wrote:

... Based on that I'd still lean toward throwing getters and purpose-built support() methods where needed.

This latter message I read as implicitly acknowledging that purpose-built support() methods are needed on occasion.

Given that sufficient interest in the problem exists, it seems that a new proposal could in theory provide just the right multiway trade-off, and that bringing up such new proposals could be good use of our time.