overload resolution consistency

At TPAC, we discussed how the behaviour of existing scripts could change 
when overloads are added to an existing interface.  That's because when 
there is no overloading, any type of value passed as an argument to an 
operation will be coerced to the correct type, but when there is 
overloading, if the type is not correct an exception will be thrown.

For example, with:

   interface A {
     void f(float x);
   };

calling f({}) is treated the same as calling f(NaN).  But if later on an 
overload is introduced:

   interface A {
     void f(float x);
     void f(DOMString x);
   };

then the call f({}) will throw a TypeError.

The suggestion was made during the meeting to make the second case not 
throw, but fall back to selecting the first operation listed on the 
interface.  That would make f({}) be the same as f(NaN) again.  People 
in the room seemed happy with this change.

There is a problem though, which is what to do when you have some 
matching types and some mismatching.  For example with:

   interface B {
     void f(object x, object y);
     void f(float x, DOMString y);
     void f(float x, float y);
     void f(DOMString x, float y);
   };

when you call f("", ""), which overload should be selected and why?

The simplest choice is probably to select the exactly matching overload 
if there is one, otherwise to select the first overload regardless of 
the types of the actual arguments.  So for the above example that would 
select f(object, object).

A less simple choice would be, if there is no exact match, to do some 
sort of counting or scoring of how well the arguments matched, and to 
select the first overload with the highest score.  So maybe you would 
say that you get 1 point for every matched types, resulting in f(float, 
DOMString) and f(DOMString, float) both scoring 1, and then you choose 
the first of these two in order of appearance.

Simpler sounds better to me, so I'll choose that unless there are some 
good reasons not to.

Received on Tuesday, 6 December 2011 04:06:52 UTC