Re: [vibration] Preliminary thoughts on the vibrator spec

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

I am (fortunately!) not a webidl expert, but based on Cameron's post,
it doesn't sound like we have much of a choice.

Since we define vibrate(unsigned long x) and vibrate(unsigned long
x[]), we'll throw if someone passes something that's not an unsigned
long or an unsigned long[], right?

I think cancelling a vibration will be sufficiently rare that using
vibrate(0) or vibrate([]) is fine.  Those two are also clearer than
vibrate() or vibrate(null).

Just to check, the types |unsigned long| and |unsigned long[]| will
catch any numeric type, right?  So we don't have to worry if someone
computes a vibration time in JS and passes in 100.0003?  That's how I
read the WebIDL spec, for what little that's worth.

It'd be easier for me to have a preference if I had more than one option.  :)

-Justin

On Wed, Nov 16, 2011 at 7:22 AM, Anssi Kostiainen
<anssi.kostiainen@nokia.com> wrote:
> 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 15:56:21 UTC