W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2011

Re: [WebIDL] Handling undefined in Overload Resolution Algorithm

From: Lachlan Hunt <lachlan.hunt@lachy.id.au>
Date: Wed, 20 Jul 2011 01:24:22 +0200
Message-ID: <4E261226.2020607@lachy.id.au>
To: Jonas Sicking <jonas@sicking.cc>
CC: public-script-coord@w3.org
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:04 UTC