Re: [WebIDL] Handling undefined in Overload Resolution Algorithm

On 2011-08-04 02:50, Cameron McCormack wrote:
> On 20/07/11 1:04 AM, Lachlan Hunt wrote:
>> Refer to discussion in a Mozilla bug 648722 [1].
>> When undefined in passed to an overloaded function, the overload
>> resolution algorithm should not exclude nullable non-primitive types.
> Thanks for all the discussion in the thread. It sounds like the
> following is what was settled on:
> * When undefined is passed, it is always treated the same as if it was
> not passed at all.

No, this is not always true for all methods.  Consider:

document.write() // writes nothing
document.write(undefined) // writes "undefined"

Although this particular case isn't overloaded, so the overload 
resolution algorithm won't be run.

> * Anywhere an undefined would help select a nullable primitive type
> during overload resolution, it should help select nullable types
> regardless of the inner type. (This would still matter in cases
> where explicit undefined is passed in the middle of the argument list,
> and later arguments are not undefined.)

Is that intended to handle this case?

e.g. consider a function

void f(in DOMString x, in DOMString y, in DOMString z);

f("a", undefined, "c")

This should not throw a type error, even if the function is overloaded.

> And finally for the API at hand:
> Element querySelector(in DOMString a, in optional Element b);
> Element querySelector(in DOMString a, in sequence<Node>? b);
> Overloads are:
> (DOMString)
> (DOMString, Element)
> (DOMString, sequence<Node>?)
> querySelector(undefined) === throw TypeError

No, I don't think that one should throw a type error.  Right now, it 
stringifies to "undefined" in implementations and doesn't throw.

Lachlan Hunt - Opera Software

Received on Thursday, 4 August 2011 09:42:58 UTC