Re: Defining a constructor for Element and friends

On 1/13/15 12:05 PM, Domenic Denicola wrote:
> From: Boris Zbarsky [mailto:bzbarsky@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

Received on Tuesday, 13 January 2015 17:19:15 UTC