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

Re: [WebIDL] Handling undefined in Overload Resolution Algorithm

From: Brendan Eich <brendan@mozilla.org>
Date: Thu, 4 Aug 2011 09:27:28 -0700
Cc: public-script-coord@w3.org
Message-Id: <874AF49C-9CA2-4AD0-A211-D702A2A02BD9@mozilla.org>
To: Boris Zbarsky <bzbarsky@MIT.EDU>
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 <cam@mcc.id.au>
>> 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.

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

Received on Thursday, 4 August 2011 16:28:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:04 UTC