Re: [vibration] Preliminary thoughts on the vibrator spec

Hi Justin, Robin, (and thanks Cameron for the status update!),

On 14.11.2011, at 22.15, ext Cameron McCormack wrote:

> 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.

Justin - Do you have a suggestion or a preference how we should handle the specific case of vibrate() overloading assuming we cannot (yet) rely on Web IDL handling the order of overloads:

[[

interface Vibration {
    void vibrate (optional unsigned long time) raises (NotSupportedError);
    void vibrate (optional unsigned long[] pattern) raises (NotSupportedError);
};

]]

  http://dev.w3.org/2009/dap/vibration/#vibration-interface

Robin - This reminds me that "raises" was removed from Web IDL in LCWD #2, 27 September 2011. Do you mind if I patch ReSpec.js v1 for that? We can continue on spec-prod, if this change should be coordinated with other editors.

-Anssi

Received on Wednesday, 16 November 2011 12:23:32 UTC