- From: Domenic Denicola <domenic@domenicdenicola.com>
- Date: Wed, 8 May 2013 18:02:43 +0000
- To: Mounir Lamouri <mounir@lamouri.fr>, "www-dom@w3.org" <www-dom@w3.org>
This is a good illustration of the kind of conflict between DOM API designers and normal ECMAScript semantics. Normal ECMAScript semantics would demand that `undefined` and no parameter be treated the same, which from what I can tell is different from what you're advocating. Furthermore, `null` should not be treated the same as `undefined`; it should throw a `TypeError` (see e.g. `Array.prototype.sort`). ES6 makes this explicit in its definition of how default parameter values work; only `undefined` (same as missing parameter) triggers use of the default, whereas `null` overrides the default. Finally, I think the correct behavior is to ignore non-Callables, instead of throwing. This allows usage of `null`, `false`, or anything else, and is consistent with e.g. `JSON.parse` and `JSON.stringify`'s optional function parameters. I don't think the spec follows this, but I admit I'm not the best at WebIDL, and the polyfill *does* follow this behavior, so it's unclear to me. In any case, the only coherent choices are either `TypeError`-except-on-callable-or-`undefined` or ignore-non-callables. Throwing errors based on the presence or absence of a parameter, even if it's `undefined`, is bizarre, and I argue additionally that treating `null` specially is also bad design. ________________________________________ From: Mounir Lamouri [mounir@lamouri.fr] Sent: Wednesday, May 08, 2013 13:23 To: www-dom@w3.org Subject: [Future] First arguments should not be optional Hi, This is an interface detail but there is no point in having the first argument of then() catch() and done() optionals. The only benefit from that is to be able to write code doing: doSomethingAsync().then().then().then().catch().done(); The only requirement I saw regarding having the first parameter optional is in GitHub issue 22 [1] but it seems that doing .then(null) or .then(undefined) should just work with current WebIDL. It is kind of a detail because the worse thing that might happen is a no-op but it seems useless to have a method being able to be called with no argument at all on purpose. [1] https://github.com/slightlyoff/DOMFuture/pull/22 Cheers, -- Mounir
Received on Wednesday, 8 May 2013 18:03:16 UTC