W3C home > Mailing lists > Public > www-dom@w3.org > April to June 2013

RE: [Future] First arguments should not be optional

From: Domenic Denicola <domenic@domenicdenicola.com>
Date: Wed, 8 May 2013 19:58:09 +0000
To: Jonas Sicking <jonas@sicking.cc>
CC: Mounir Lamouri <mounir@lamouri.fr>, "www-dom@w3.org" <www-dom@w3.org>
Message-ID: <B4AE8F4E86E26C47AC407D49872F6F9F7EF891EB@BY2PRD0510MB354.namprd05.prod.outlook.com>
From: Jonas Sicking [jonas@sicking.cc]

> On Wed, May 8, 2013 at 11:02 AM, Domenic Denicola <domenic@domenicdenicola.com> wrote:
>> Finally, I think the correct behavior is to ignore non-Callables, instead of throwing.

> Out of curiosity, why do you prefer that behavior? As an author I would feel that it's pretty hostile for an API to simply ignore what I requested, rather than letting me know through a thrown exception.

It's just more lenient, aligning better with existing JS libraries I've seen (not just promise ones). The spec evidence is pretty sparse---`Array.prototype.sort` versus `JSON.stringify` and `JSON.parse`. But in my experience most libraries will do either a `typeof x === "function"` test or a `if (x)` test before usage; none will do `if (typeof x !== "function" && typeof x !== "undefined")` test.

As a concrete example of how this is useful, consider

```js
var onFulfilled = handlers && handlers.onFulfilled;
promise.then(onFulfilled).done();
```

If `handlers` is `null` then this will break if only `undefined` is accepted; instead you must do

```js
var onFulfilled = handlers ? handlers.onFulfilled : undefined;
```

It's a pretty minor point though, all said. Allowing only `undefined` is fine too.
Received on Wednesday, 8 May 2013 19:58:41 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:20 UTC