W3C home > Mailing lists > Public > public-device-status@w3.org > November 2011

Re: [vibration] Preliminary thoughts on the vibrator spec

From: Cameron McCormack <cam@mcc.id.au>
Date: Tue, 15 Nov 2011 09:15:45 +1300
Message-ID: <4EC176F1.4040900@mcc.id.au>
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:41 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:42:59 UTC