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

Re: [WebIDL] Handling undefined in Overload Resolution Algorithm

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Tue, 19 Jul 2011 21:53:20 -0400
Message-ID: <4E263510.2090805@mit.edu>
To: public-script-coord@w3.org
On 7/19/11 7:53 PM, Allen Wirfs-Brock wrote:
> 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:

Well, if you don't check arguments.length, as you point out.  Just like 
in the C++ implementation of this, actually... ;)

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

That's one of the things that needs to be specced here.

For what it's worth, consider the following code:

   elem.querySelector(str, x.firstChild)

If "x" has no firstChild, can you tell whether this will pass null or 
undefined, without knowing whether x happens to be a Node, etc?

If the argument is that we don't want to magically use |elem| as the 
context if there happens to be no firstChild property on x, then it 
would make sense to make both undefined and null use no context.  But 
then passing undefined needs to not have the same behavior as passing 
only one argument.

On the other hand, if we require that undefined and only one argument 
act the same, then either passing undefined and null behave differently, 
or both use |elem| as the context, which is a slightly weird thing to do 
when someone tried to explicitly pass a different scope in....

That's about the state of things so far; Jonas and I can't decide which 
of these options is worse.  ;)

-Boris
Received on Wednesday, 20 July 2011 01:53:48 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 May 2013 19:30:04 UTC