Re: [WebIDL] Handling undefined in Overload Resolution Algorithm

Lachlan Hunt:
>>> 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.

Cameron McCormack:
>> Actually, I did recently remove the different behaviour between
>> overloaded and non-overloaded operation invocation.  So it does look
>> like treating undefined the same as omitting the argument entirely does
>> not work across the board.

Jonas Sicking:
> window.alert() probably has the same issue.
> But if document.write and window.alert are the only examples of this,
> I don't think we need to adjust all of WebIDL to it. It's easy enough
> to describe this exception in prose.

If there are just one or two exceptions, and people are happy with the 
general approach of "undefined means the same as missing (optional?) 
argument", then we could do just that.

>> If however you had
>>   void f(in DOMString x, in DOMString y, in DOMString z);
>>   void f(in DOMString x, in float y, in DOMString z);
>> and you called `f("a", undefined, "b")`, then it would use undefined to
>> help distinguish between those two, and it would choose the second one.
> Out of curiosity, why the second?

Because the overload resolution algorithm currently eliminates a 
candidate if the value passed is undefined and the type of the argument 
is not a primitive type (boolean, integer types, float, double) or 
nullable versions of those.

If we allow undefined to select an operation whose argument type is 
DOMString, then we would make the following ambiguous:

   void f(in DOMString x);
   void f(in unsigned long x);

so disallowed in IDL.  I had thought that having overloads differing 
only by a DOMString vs primitive type argument would be necessary, but 
looking just now at the HTML5 and DOM Core IDL I can't see any use of 
this, so perhaps we can lump DOMString in with the other primitive types.

If we do need to distinguish these two, we could special case it to 
always favour the DOMString over the primitive type or vice versa, if 
necessary, but I would like to avoid complicating the overload 
resolution algorithm any further.

> I think we should only treat<undefined>  as "not specified" for
> optional arguments. For required arguments it would seem like using
> the normal coercion algorithm makes the most sense.
> If for no other reason, otherwise it's impossible to specify a function like
>    void foo(in any a);
> and be able to call that with
> This is something that is needed by at least IndexedDB and postMessage.

That is a good point about passing undefined to "any".

Currently, operations with optional arguments are purely sugar for 
overloads with the different variations of missing arguments, e.g.

   void f(in optional DOMString x);
   void f(in object y);

is exactly the same as

   void f();
   void f(in DOMString x);
   void f(in object y);

so if possible, I would like to avoid ascribing different behaviour to 
the two.  I think it could be confusing, especially if the difference is 
only in this kind of edge case of passing undefined.

Received on Monday, 8 August 2011 21:44:02 UTC