Respec: Change overload naming algorithm

[saschanaz]

We agree that current !overload-1 is weird, so I suggest a change:

interface mixin Foo {
  void overload(); // this should be just foo-overload
  void overload(short s); // foo-overload-s
  void overload(long s); // foo-overload-s-1
  void overload(DOMString str, object obj); // foo-overload-str-obj
};

Basically we name the operations by its argument names, and if some of them collides, then attach -(counter).

@marcoscaceres and @sidvishnoi, what do you think?

[sidvishnoi]

I'm in favor of using parameter types instead of names. That feels more natural and is less likely to be changed than names. Though it may result in longer id.
+1 on adding counter on collision.

[saschanaz]

I'm in favor of using parameter types instead of names. That feels more natural and is less likely to be changed than names. Though it may result in longer id.

Especially when the list includes generics or unions. I don't disagree, though:

interface mixin Foo {
  void overload(); // this should be just foo-overload
  void overload(short s); // foo-overload-short
  void overload(long s); // foo-overload-long
  void overload(DOMString str, object obj); // foo-overload-domstring-object
  void overload(Promise<DOMString> p, sequence<ByteString> s); // foo-promise-domstring-sequence-bytestring
  void overload(optional (Dict or boolean) opt); // foo-overload-dict-boolean
};

Hopefully it won't be too complex in most of situations.

[saschanaz]

One problem is that we already are using argument names for non-overloads, and those will drastically change if we choose the type name way. 🤔

[marcoscaceres]

The numbering is very fragile, so definitely needs to go away (eg, if a new overload is added, it breaks). I don't think we should have "overload" in the id either. The uniqueness comes from the args their respective types, so I feel that should form the ID.

More importantly, we need to think about how Editors define and link to overloads without even needing to use the id.... Foo/overload(short x) for instance. Same for overloaded constructors.

[saschanaz]

overload in the example is just the name of the operation 🤣

[marcoscaceres]

Oh woops! Lol

[saschanaz]

Looking at the core/inline-idl-parser, it seems it currently treats things between parentheses as "argument values" and thus wraps them as <var>. Can it be modified to also use "parameter names" there without breaking existing code?

[marcoscaceres]

Can it be modified to also use "parameter names" there without breaking existing code?

Should be fine I think... we can deal with breakage.

[saschanaz]

I think both are valid use cases, could we support both? 🤔 What does bikeshed do?

[marcoscaceres]

I'm not sure what Bikeshed does :( Any chance you could have a look? I don't mind if we follow whatever it does.