- From: Jonas Sicking <jonas@sicking.cc>
- Date: Tue, 19 Jul 2011 15:49:00 -0700
- To: Lachlan Hunt <lachlan.hunt@lachy.id.au>
- Cc: public-script-coord@w3.org
On Tue, Jul 19, 2011 at 11:58 AM, Lachlan Hunt <lachlan.hunt@lachy.id.au> wrote: > On 2011-07-19 19:06, Jonas Sicking wrote: >> >> On Tue, Jul 19, 2011 at 6:04 AM, Lachlan Hunt<lachlan.hunt@lachy.id.au> >> wrote: >>> >>> Hi, >>> Refer to discussion in a Mozilla bug 648722 [1]. >>> >>> When undefined in passed to an overloaded function, the overload >>> resolution >>> algorithm should not exclude nullable non-primitive types. >> >> I'm not quite sure I understand what you are suggestion. Are you >> saying that we should treat undefined as null when calling a function >> that takes a nullable type? > > That's what the algorithm already says when the parameter is a nullable > primitive type. I don't really have a strong opinion either way, the point > is just to make all nullable types consistent when undefined is passed. 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. To give a bit more context: The second argument to this function defines a context in which it evaluates a CSS selector. If the second argument is not specified, the function uses the this-object as a default context. I'd love it if people with more experience of the various JS APIs that are floating around out there, especially if you can point to other APIs that has set a precedence. / Jonas
Received on Tuesday, 19 July 2011 22:49:59 UTC