Re: [WebIDL] Handling undefined in Overload Resolution Algorithm

On Mon, Aug 8, 2011 at 2:43 PM, Cameron McCormack <cam@mcc.id.au> wrote:
> 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.

I'm certainly happy with it.

>>> 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 do think we should lump DOMString with other primitives. In fact,
I'd prefer to simply say "string" in the IDL.

I do definitely agree that we don't want to complicate the overload
resolution algorithm though. In particular in a way that would cause
slower performance. But don't you have to deal with this anyway if
there are two functions like

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

>> 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
>>
>> x.foo(undefined);
>>
>> 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.

100% Agreed!

I guess that would mean that we'd have to say that 'undefined' also
has special meaning if there are overloads that take fewer arguments
too. In addition to saying that it has special meaning if there are
overloads which take optional arguments.

Which complicates the overload algorithm. Which is a bummer :(

It still seems to me that it's the better thing to do though.

/ Jonas

Received on Monday, 8 August 2011 21:57:55 UTC