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

Re: [vibration] Preliminary thoughts on the vibrator spec

From: Anssi Kostiainen <anssi.kostiainen@nokia.com>
Date: Mon, 14 Nov 2011 15:30:32 +0200
Cc: Justin Lebar <jlebar@mozilla.com>, public-device-status@w3.org, "public-device-apis@w3.org WG" <public-device-apis@w3.org>
Message-Id: <2C6EACD7-73B5-417A-8594-967B737EBE75@nokia.com>
To: ext Jonas Sicking <jonas@sicking.cc>
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?

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:32:32 UTC