Purpose of call-a-user-object’s-operation’s opName parameter

[bathos]

Callback interfaces are required to have one-and-only-one regular operation*. The single operation has a particular known name. However call a user object’s operation requires an opName parameter. This permits the algorithm to be invoked with a different name than was given in the callback interface definition for the type that value is an instance of.

The only usages of the algorithm I could find are in the DOM spec, which always passes an opName that does align with the name of the CBI’s operation member. Is there any reason for this parameter to exist given it’s a static part of the type definition? It seems likely that it’s unintentional that it permits passing a different name.

* Which isn’t really an operation in the same sense that word is used elsewhere in the spec; it just uses the same syntax.

[domenic]

Agreed, this seems like a mistake!

[annevk]

As per https://dontcallmedom.github.io/webidlpedia/names/ all callback interfaces are indeed in DOM and follow this pattern. So this could be simplified.

[bathos]

Found more context for this: callback interfaces were permitted to have multiple operation members (and attributes) prior to #696, which removed these capabilities because they weren’t really in use. The opName parameter is a relic from before that update.

I also found an implementation relic of this in Blink, where callback interfaces can be kNotSingleOperation (but never actually are).