Re: [WebIDL] Handling undefined in Overload Resolution Algorithm

On Thu, Aug 4, 2011 at 9:27 AM, Brendan Eich <> wrote:
> On Aug 4, 2011, at 6:24 AM, Boris Zbarsky wrote:
>> On 8/4/11 4:44 AM, Anne van Kesteren wrote:
>>> On Thu, 04 Aug 2011 02:50:38 +0200, Cameron McCormack <>
>>> wrote:
>>>> Let me know your thoughts.
>>> In general this sounds good to me. Has anyone tested legacy APIs like
>>> the open() method of XMLHttpRequest to see if you get the same? I sort
>>> of thought undefined was passed through, but maybe I misremember.
>> In Gecko, undefined used to be treated as "not specified" for XMLHttpRequest.  When we changed to following the current spec (which converts undefined to "undefined") we actually ran into compat issues with some popular JS libraries that pass undefined for username/password explicitly.  For now we're sticking it out, but it sure would be nice to not have those compat issues!
> JS has always (via arguments.length testing) allowed "arity-based dispatch" to be simulated. It's not the same as undefined actual argument detection or (as noted here) conversion, which often bites back.
> For overload resolution, actual argument count matching one of N overload's formal parameter count is necessary (sorry if I'm rehashing).
> For a single, unoverloaded method, there still may be good reason to check actual argument count before blindly converting optional trailing parameters. It seems like XHR may have methods of this kind.

The question comes down to this: Is it more "javascripty" to look at
the actual argument count (in JS terms, check arguments.length), or is
it more "javascripty" to look at which arguments have the value

The assertion thus far has been that checking which arguments have the
value <undefined> is more common in various JS libraries and API.
Hence it's better if we make the DOM follow that convention. This
would mean that for optional arguments we don't check how many were
passed to the function, but rather how many were passed and did not
have the value <undefined>.

> Is Gecko alone in "sticking it out" on this particular case?

I think at least Gecko is all over the map here since we have many
different ways of checking for optional arguments and since there
hasn't been a spec for most of these APIs, it's varied from function
to function what we do.

So my guess is that there's very little consistency both between
browsers and within browsers here.

/ Jonas

Received on Thursday, 4 August 2011 23:41:04 UTC