- From: Justin Lebar <jlebar@mozilla.com>
- Date: Mon, 14 Nov 2011 08:40:26 -0500
- To: Anssi Kostiainen <anssi.kostiainen@nokia.com>
- Cc: ext Jonas Sicking <jonas@sicking.cc>, public-device-status@w3.org, "public-device-apis@w3.org WG" <public-device-apis@w3.org>
> Anyone having objections against dropping null? 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?) -Justin On Mon, Nov 14, 2011 at 8:30 AM, Anssi Kostiainen <anssi.kostiainen@nokia.com> wrote: > 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:46:25 UTC