- From: Anssi Kostiainen <anssi.kostiainen@nokia.com>
- Date: Mon, 14 Nov 2011 15:30:32 +0200
- To: ext Jonas Sicking <jonas@sicking.cc>
- Cc: Justin Lebar <jlebar@mozilla.com>, public-device-status@w3.org, "public-device-apis@w3.org WG" <public-device-apis@w3.org>
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:41 UTC