- From: Boris Zbarsky <bzbarsky@mit.edu>
- Date: Tue, 13 Jan 2015 00:49:23 -0500
- To: Domenic Denicola <d@domenic.me>, Anne van Kesteren <annevk@annevk.nl>, WebApps WG <public-webapps@w3.org>, "www-dom@w3.org" <www-dom@w3.org>
On 1/11/15 2:33 PM, Domenic Denicola wrote: > "Terminology: In what follows I use 'own-instances of X' to mean objects where obj.constructor === X, That doesn't make much sense to me as a useful test, since it's pretty simple to produce, say, an HTMLParagraphElement instance on the web that has whatever .constructor value you desire, right? Unless the intent is to talk about this in some setup where no one has messed with any of the objects or something. I guess the intent here is that we want obj to have been constructed via X in some sense? Modulo whatever the story is for the things that have NamedConstructors. > as distance from 'instances of X' which means objects for which obj instanceof X." OK. Anyway, modulo exactly what this definition should be, let's talk about the proposed "the constructor of an element determines its set of internal slots" invariant. I'm OK with that if we include "constructor arguments". Otherwise, I don't see how it can make sense. In particular, say someone does: var x = new Element("a", "http://www.w3.org/1999/xhtml") or whatever argument order we do. Per invariant 1 in your document, this should get the internal slots of an HTMLAnchorElement, right? Per invariant 2, x.constructor == Element, and in particular x.__proto__ == Element.prototype. So suddenly we have an HTMLAnchorElement as an own-instance of "Element", which I think violates your invariant 3. Moving on to invariant 4, is that "instances" in terms on instanceof (which can be almost tautologically true, given what Web IDL says about [[HasInstance]] on interface objects), or in terms of what the proto chain looks like, or something else? In particular, the "x" defined above doesn't have HTMLElement.prototype on its proto chain, but is instanceof HTMLElement... >> I'd like to understand what you mean by "interface is Element" here, exactly. > > I'm just quoting Anne :). My interpretation is that the (object representing the) element is an own-instance of Element. This _really_ requires pinning down what exactly own-instance means. Let's get our terminology in order. ;) The one piece of terminology that I think we have so far that I understand is what it means for an object to "implement an interface". At least Web IDL has a normative requirement on such a thing being defined (e.g. see http://heycam.github.io/webidl/#es-operations step 4 of the behavior), presumably in terms of some sort of branding. So it makes sense to me to talk about things implementing Element but not any interface that has Element as an inherited interface. That would correspond to "is an Element but not any specific subclass of Element". Could use a shorter way of saying it, for sure. -Boris
Received on Tuesday, 13 January 2015 05:49:54 UTC