Re: [WebIDL] Handling undefined in Overload Resolution Algorithm

On Jul 19, 2011, at 3:49 PM, 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.

#2
elm.querySelector(myself, undefined)  and elm.querySelector(myself) are borderline indistinguishable from the perspective of elm.querySelector if it was implemented as an ECMAScript function.  Assume that such a function is defined as:

function querySelector(sel, ctx) {
    ...
}

within the body of the function the value of ctx will be the value undefined for either of those calls.  The code pattern you are most likely to see for such a function would be to test if ctx was undefined and assume that meant the argument was not supplied regardless of whether it was done implicitly via a single argument call or explicitly by passing undefined as the second argument. 

The ES code of such a function actually can explicitly check the number of arguments that were actually passe via arguments.length but in most cases a developer probably wouldn't bother to do so as it really doesn't make such of a different.  

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

What does null mean as the second argument?  Use no context at all?

> 
> 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 23:54:15 UTC