[whatwg/dom] Proposal: Allow WebIDL bindings to expose method parameters' types (Issue #1182)

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](https://github.com/w3c/mediacapture-screen-share/issues/260). François' proposal is interesting. I'd like to enrich the discussion by adding one more possible solution.

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

interface SomeDictionary {
  boolean boolField;
  int intField;
  int otherIntField;
  SomeEnum someEnumField;
}

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

The new tag would then produce bindings that would allow something like this:
```js
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:
```js
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.


-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/1182
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/issues/1182@github.com>