Re: [WebIDL] Handling undefined in Overload Resolution Algorithm

Cameron McCormack:
>> 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.

Jonas Sicking:
> I'm certainly happy with it.

I'll investigate existing APIs to see how many we would need to annotate 
with "explicit undefined doesn't mean missing argument" behaviour.

> I do think we should lump DOMString with other primitives. In fact,
> I'd prefer to simply say "string" in the IDL.

There was some desire to change "DOMString" to "string" in the past, but 
I thought it was you who objected, due to "string" meaning something 
different in our XPIDL stuff.  If there actually are no objections, then 
I would prefer to make that change too. :-)

I will take a more thorough look at existing IDL to see whether 
DOMString vs primitive type overloading is necessary at the moment.

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

That is already disallowed in IDL, since they're both primitive types. 
The table at http://dev.w3.org/2006/webapi/WebIDL/#dfn-distinguishable 
shows which types can be used to distinguish overloads.

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

Sorry, I got a bit confused with the above.  Are you saying that you 
think it's better to complicate the overload algorithm in this case to 
make explicit undefined passed to an operation with an optional argument 
mean the same thing as leaving it out, but for actual overloads for it 
to mean a value was indeed passed (and to cause it to match any 
primitive type plus DOMString)?

The special casing of window.alert, document.write and whichever other 
ones are necessary, and having explicit undefined in all other cases 
(whether with optional arguments or actual overloads) mean the same 
thing as an omitted argument seems simpler to me.

Received on Monday, 8 August 2011 22:14:50 UTC