[Bug 14877] Define [[Class]] of interface prototype objects, exception interface objects, and exception interface prototype objects

http://www.w3.org/Bugs/Public/show_bug.cgi?id=14877

--- Comment #11 from Aryeh Gregor <ayg@aryeh.name> 2011-11-21 20:07:34 UTC ---
(In reply to comment #8)
> If DOMException is spec changed to be a function then the Interface
> Object's prototype -- DOMException.prototype -- can then be defined to be
> an instance of DOMException. This is how all the built-ins work, e.g.
> 
>  Function.prototype instance of Function; // true
>  String.prototype == ""; // true
>  Error.prototype instanceof Error; // true

Function.prototype instanceof Function is false in Firefox 11a1, Chrome 17 dev,
and Opera 12.00, and that appears to me correct per spec:

http://es5.github.com/#x15.3.5.3

Regardless, the behavior is out of WebIDL's control, unless it wants to define
a special [[HasInstance]] internal method for its functions (I don't think it
does).  WebIDL gets to say what everything's [[Prototype]] is, and
[[HasInstance]] (= instanceof) behavior follows from that.

> Those Interface Objects can't be new'd. What type of Element would
> Element.prototype be? What of its ownerDocument? 

Element.prototype is an object with all the properties you'd expect on any
Element.  However, the descriptors of properties like ownerDocument are
accessor descriptors, not data descriptors, and the getters/setters are defined
to throw if you call them on something that's not an instance.  So
Element.prototype.ownerDocument just throws, as do Element.prototype.nodeType
and all the rest.

> However programs should be able to expect a toString method on host objects. By
> spec'ing Object.prototype as a base, Object.prototype.toString would be
> guaranteed available, instead of an error or some strange host object behavior

Everything should be inheriting eventually from Object.  That's not the issue
under discussion.

(In reply to comment #10)
> Also, it's important to say the role of [[Class]], since ES6 drafts remove that
> internal property in favor of generic (class-independent) semantics, or else a
> more precise and less over-loaded internal nominal tagging scheme. I'm assuming
> here the issue is Object.prototype.toString.

Yes, exactly.  That's all I actually care about.  The only way ES5 gives us to
define Object.prototype.toString behavior is via [[Class]], so that's how
WebIDL has to define it.  The other places in the ES5 where [[Class]] is used
don't matter for this bug -- none of them care what [[Class]] is except if it's
"Array", "Boolean", "Function", "Number", "RegExp", or "String", if I didn't
miss any.  Any other [[Class]] is entirely arbitrary except for
Object.prototype.toString.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

Received on Monday, 21 November 2011 20:07:40 UTC