- From: Lachlan Hunt <lachlan.hunt@lachy.id.au>
- Date: Wed, 20 Jul 2011 01:24:22 +0200
- 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. http://dev.w3.org/2006/webapi/WebIDL/#es-nullable-type 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 undesirable. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Received on Tuesday, 19 July 2011 23:24:59 UTC