Re: [WebIDL] Handling undefined in Overload Resolution Algorithm

On 2011-07-20 00:49, Jonas Sicking wrote:
> I'd really like to hear from people that have more experience with
> Javascript-specific APIs than I do. So given a function that produces
> different results for:
> elm.querySelector(mysel, null);
> vs.
> elm.querySelector(mysel);
> what would you expect something like:
> elm.querySelector(myself, undefined)
> to do? Should it
> 1) Behave like elm.querySelector(mysel, null)? I.e. treat undefined as null.
> 2) Behave like elm.querySelector(mysel)? I.e. treat undefined as not
> passing the argument at all.

Pretending for a moment that querySelector isn't an overloaded function, 
and say it only included the definition with the sequence<Null>? parameter:

Element querySelector(in DOMString selectors, in sequence<Node>? refNodes);

Passing undefined to that function, according to the current 
requirements in the WebIDL draft, the JS values of undefined and null 
are both converted to IDL null values in the ECMAScript to IDL 
conversion algorithm for nullable types.

Step 2 states:

   Otherwise, if V is null or undefined, then return the
   IDL nullable type T? value null.

Regardless of whether that's the best handling of undefined for nullable 
types, the issue that needs to be resolved, however, is that because the 
method is actually overloaded (the other alternative accepting an 
optional Element node), the overload resolution algorithm in WebIDL 
picks neither and, I believe, throws an exception, which is very 

Lachlan Hunt - Opera Software

Received on Tuesday, 19 July 2011 23:24:59 UTC