- From: Cameron McCormack <cam@mcc.id.au>
- Date: Tue, 15 Nov 2011 09:15:45 +1300
- To: Justin Lebar <jlebar@mozilla.com>
- CC: Anssi Kostiainen <anssi.kostiainen@nokia.com>, ext Jonas Sicking <jonas@sicking.cc>, public-device-status@w3.org, "public-device-apis@w3.org WG" <public-device-apis@w3.org>
On 15/11/11 2:40 AM, Justin Lebar wrote: > I don't care if we do or don't have null, but does it make sense in > terms of the WebIDL overload to drop null? I'd think that if null is > appropriate to pass to function which takes unsigned long, then > passing it to the overloaded function wouldn't throw an error. > (Similarly, I'd expect passing a single number to a function which > takes an unsigned long[] to cause an error, but you can obviously pass > a number to vibrate(). So why is a number not an error while null > is?) One unfortunate aspect of how overloading is currently defined in Web IDL is that there is a difference in how incorrect types passed to a function are handled when there is vs isn't overloading. So with: void f(unsigned long x); calling the function with any value will first do a ToNumber() and not throw because you pass a value that is not a Number. But with: void f(unsigned long x); void f(DOMString x); if you pass anything that is not a Number or a String, then a TypeError will be thrown. I think everyone thinks this sucks, and at TPAC the other week an idea was floated to have the order of overloads be meaningful and to have the first one be the one that's called when the types are not exactly correct.
Received on Monday, 14 November 2011 20:16:38 UTC