Re: [vibration] Preliminary thoughts on the vibrator spec

On 10.11.2011, at 19.18, ext Jonas Sicking wrote:

> On Thu, Nov 10, 2011 at 4:10 AM, Anssi Kostiainen
> <anssi.kostiainen@nokia.com> wrote:
>> 
>> 
>> The arguments are type of 'unsigned long' and 'unsigned long[]'. According to Web IDL (http://dev.w3.org/2006/webapi/WebIDL/#es-unsigned-long):
>> 
>> * negative values throw a TypeError
>> 
>> * undefined throws a TypeError (ToNumber(undefined) === NaN as per ECMA-262, and NaN throws TypeError as per Web IDL)
>> 
>> * null is converted to 0 (ToNumber(null) === +0 as per ECMA-262), and thus vibrate(null) should behave similarly to vibrate(0)
>> 
>> Given this, I dropped undefined, but kept null. So all these will cancel the operation similarly:
>> 
>> vibrate(null)
>> vibrate(0)
>> vibrate([])
>> 
>> Does this sound reasonable?
> 
> Is this the case even when there are overloads? In that case type
> coercion happens much more rarely since we don't know what type to
> coerce to.

According to Web IDL (http://dev.w3.org/2006/webapi/WebIDL/#es-array) if an array is expected but null is passed a TypeError is thrown (ToObject(null) throws TypeError as per ECMA-262).

I'm wondering if the easiest solution would indeed be to drop null from the following processing step as per Jonas' original proposal:

[[

* If pattern is 0, an empty list, or null, cancel the pre-existing instance of the processing vibration patterns algorithm, if any, and abort these steps.

]]

Anyone having objections against dropping null?

-Anssi

Received on Monday, 14 November 2011 13:31:42 UTC