Re: new overloading model

I did find one problem while writing up the spec change for this.

The existing rule is that there must be at least one index in the 
effective overload set entry type lists where the types at that index 
are all distinguishable.  That still doesn't forbid the following, though:

   void f(Node a, Node b, DOMString c);
   void f(Node a, DOMString b, Node c);

At each index all of the types are distinguishable, but it still doesn't 
help if you call

   f(node, false, false);

false is a value that should be converted to a DOMString, but it's not 
clear which of the two overloads to choose.

So instead the rule should be:

   * there must be at least one index where the types are all
     distinguishable, and
       * all the types are also exactly matchable (= not primitives
         or DOMString), or
       * there is only one such index.

In the above example, there are two indices where the types are all 
distinguishable (1 and 2), and at neither of them are all the types 
exactly matchable.

This is OK:

   void g(Node a, Node b);
   void g(Node a, DOMString b);

because there's only one index where the types are distinguishable and 
not all exactly matchable.

The overload resolution algorithm can be even simpler; instead of going 
through each index of the type lists of the entries, you look only at 
the first index where all types are distinguishable and exactly 
matchable, or if there's no such index, the first and only index where 
the types are all distinguishable (where they're not all exactly matchable).

Based only on the type of JS value you have at that argument position, 
you can determine which entry of the effective overload set to use.

Received on Thursday, 22 December 2011 05:08:26 UTC