Re: [WebIDL] Proposing changes to overload resolution behavior

Hi Kyle.

On 10/10/11 7:20 AM, Kyle Huey wrote:
> First, my apologies if this has been brought up before, I haven't been
> following this list in the past.

I don't think it has.

> I have been considering how to implement WebIDL's overloading behavior
> in Gecko.  There are some parts of the spec that will make this behavior
> quite difficult to implement:
>
> 1. Allowing the overload resolution behavior to be specified on a
> per-interface basis will require a significant amount of implementation
> complexity for questionable benefit.  Rather than disambiguation
> behavior for the case:
>
> interface A {
>    // ...
> };
>
> interface B {
>    // ...
> };
>
> interface C {
>    void f(A? x);
>    void f(B? x);
> };
>
> being specified by interface C (and being arbitrarily complex!), I
> propose that in any ambiguity in the overloads be resolved with
> whichever method is declared first in the interface "winning".  Specs
> can be written to deal with this limitation.

Currently the order of overloaded operations on an interface doesn't 
have any effect, so this would be the first.  This isn't a huge problem, 
but it does mean that we would need to define how the ordering works 
across multiple "partial interfaces", since they are also currently 
considered unordered.  (Maybe we could just disallow having overloads 
spread across partials?)

So as far as I know, there aren't (yet) any specs that define custom 
disambiguation behaviour.  I believe the only situations where the spec 
says things are distinguishable when they might not be is objects 
implementing multiple interfaces and nullable interface types.  I wonder 
if we can just get rid of the second case altogether, so that the above 
interface would need to be written as:

   interface C {
     void f(A? x);
     void f(B x);
   };

On the other hand, it's quite likely that APIs written using overloading 
like in your quoted example will have the same behaviour if you consider 
the null to be passed to either of the two overloads (and there is some 
spec text in there to say that if the interface definition does not 
explicitly define how to disambiguate in this case, that one is chosen 
arbitrarily), so I wouldn't be opposed to two nullable interfaces types 
being considered distinguishable and just selecting the first one.

> 2. Allowing interfaces to be distinguishable solely based on interface
> identity is problematic.  Consider the following:
>
> interface A {
>    // ...
> };
>
> interface B : A {
>    // ...
> };
>
> interface C {
>    void f(A? x);
>    void f(B? x);
> };
>
> If one passes in an object implementing interface B to C::f, which
> overload should be invoked?  This is problematic for us from C++ too
> where determining which overload to call depends on determining the most
> derived class (which is completely doable, but slow and annoying).  I
> propose that we modify the definition of distinguishable interfaces to
> be distinct interfaces where one interface does not lie on the
> inheritance chain of the other.

Yeah, I don't think we have any need to support overloading of two 
interfaces in the same inheritance chain.  Let's disallow that.

Received on Monday, 24 October 2011 17:50:08 UTC