W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2013

RE: Maybe we should think about Interface.isInterface functions again

From: Domenic Denicola <domenic@domenicdenicola.com>
Date: Sat, 20 Jul 2013 19:36:57 +0000
To: Anne van Kesteren <annevk@annevk.nl>, Boris Zbarsky <bzbarsky@mit.edu>
CC: Travis Leithead <travis.leithead@microsoft.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>
Message-ID: <B4AE8F4E86E26C47AC407D49872F6F9F878584FE@BY2PRD0510MB354.namprd05.prod.outlook.com>
+1 to the throwing-getter being very confusing; `undefined` would make more sense, just like it would for any other property that does not apply such as `asdf` or `qqqqqqq`.

Anyway, nitpicking this particular example is not productive---we don't want to be the guys responding to multiple instances of "please add this feature" with "ur doin it wrong"---so we can leave the what-should-the-getter-do as a side discussion. Anne points out a great example where, even without weird throwing getters, `instanceof Node` doesn't do what you want.

It seems like there's two tests being asked for here:

1. "is a node," which `HTMLElement.prototype` should actually pass (it's the prototypical `HTMLElement`, and will have all the same properties of any other `Node`). This would in my opinion be covered by `x instanceof Node`.
2. "can be appended," which `HTMLElement.prototype` should fail. This is where introducing something new would make sense, e.g. `node.canAppendChild(HTMLElement.prototype) === false`. Of course we'd also have `node.canAppendChild({ arbitrary: "object" }) === false` and so on.

Received on Saturday, 20 July 2013 19:37:30 UTC

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