- From: Cameron McCormack <cam@mcc.id.au>
- Date: Mon, 24 Oct 2011 10:49:28 -0700
- To: Kyle Huey <me@kylehuey.com>
- CC: public-script-coord@w3.org
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