Re: [WebIDL] Handling undefined in Overload Resolution Algorithm

On Tue, Jul 19, 2011 at 4:53 PM, Allen Wirfs-Brock
<> wrote:
> 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.

That makes sense for me.

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


/ Jonas

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