Re: [WebIDL] Proposing changes to overload resolution behavior

On Mon, Oct 24, 2011 at 1:49 PM, Cameron McCormack <cam@mcc.id.au> wrote:

> 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?)
>

I was kind of hoping that this was already disallowed.  Making it work
sanely seems hard.

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.


I don't have strong opinions here either way.

 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.
>
> Cool.

Thanks,

- Kyle