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
