On 1/13/15 12:05 PM, Domenic Denicola wrote:
From: Boris Zbarsky [mailto:bzbar...@mit.edu]
var x = new Element("a", "http://www.w3.org/1999/xhtml";)
The idea is that your above example throws, preserving the invariant.
That sounds annoying....
Presumably this means that document.createElement(NS) looks up the
registry constructor and calls it, instead of calling the Element
constructor and having _that_ delegate to the registry.
But it also means that user-space code that has to create an HTML
element generically now has to go through document.createElement instead
of being able to do |new HTMLElement("a")|, right?
I agree that this does allow us to preserve the invariant in question,
but I question whether it's worth it.
I was assuming non-exotic [[HasInstance]]
Ah, yeah, with Web IDL that's not a good assumption
but I agree it's ambiguous given that. I meant prototype chain. Probably I also
implicitly meant internal slots.
Those aren't the same thing at all, right? The prototype chain has
absolutely nothing to do with internal slots, unless we're assuming some
sort of vanilla untouched tate of the world.
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.
Heh, I don't really understand what that means; I indeed noticed that Web IDL
uses it without defining it.
Right now the concept of what it means for a "platform object" to
"implement an interface" is sort of up to the implementation. The Web
IDL spec assumes that for each platform object there is a set of
interfaces it implements, subject to some constraints described in
<http://heycam.github.io/webidl/#es-platform-objects>, but even basic
restrictions like "if A inherits from B and the platform object
implements A then it must implement B" don't seem to be explicitly
stated.... We should really fix that.
I too would guess that it's branding-related.
That's certainly how implementations treat it in practice.
Note that in any sensible scheme I can think of, subclass instances (for a
subclass that calls super() in the constructor) also get the brands of their
superclass.
Yes, absolutely.
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.
Don't think this attempt at pinning down terminology works for user-defined
subclasses of Element. E.g. as far as I can tell, `new (class X extends Element
{})()` has only the Element brand but no other brand (since X didn't install
any brands itself). But I would say that it's an own-instance of X instead of
an own-instance of Element.
OK. That makes sense; I'm not trying to redefine the concept of
"own-instance". I'm just trying to figure out what the right concepts
are to define.
The concept of "implements an interface" has to do with branding and
guaranteed existence of internal slots and whatnot. The concept of "has
Element as its primary interface" also promises something about the
initial value of __proto__.
The concept of own-instance, if we define it as you did above ("was
created by") would also guarantee certain things about branding and
internal slots. It would also make some guarantees about the prototype,
assuming no one sets __proto__ after that...
Really, this idea of "primary interface" and your idea of "own-instance"
seem fairly similar, right? Except that "primary interface" can only
refer to Web IDL interfaces, not user-defined subclasses... or something.
-Boris
