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: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Sat, 20 Jul 2013 16:49:39 -0400
Message-ID: <51EAF7E3.80806@mit.edu>
To: Domenic Denicola <domenic@domenicdenicola.com>
CC: Anne van Kesteren <annevk@annevk.nl>, Travis Leithead <travis.leithead@microsoft.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>
On 7/20/13 3:36 PM, Domenic Denicola wrote:
> +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`.

This is a bit different from the 'asdf' case, since 
Node.prototype.hasOwnProperty("ownerDocument") returns true...  But yes, 
we could try doing the LenientThis thing for getters if people are not 
too worried about the boolean case.

> Anne points out a great example where, even without weird throwing getters, `instanceof Node` doesn't do what you want.

Yep.

> 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`).

Well, so....  It has the properties, but you can't do anything useful 
with them for the most part.  This is not "is a node" in the sense that 
most consumers of these APIs think of as "is a node".

> 2. "can be appended," which `HTMLElement.prototype` should fail

It would also fail "can be adopted", "can get first child", etc, etc. 
I'm not sure that adding a special test for every single DOM method is 
the right solution to this problem...

-Boris
Received on Saturday, 20 July 2013 20:50:08 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:37:50 UTC