W3C home > Mailing lists > Public > public-script-coord@w3.org > October to December 2011

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

From: <bugzilla@jessica.w3.org>
Date: Fri, 16 Dec 2011 04:08:18 +0000
To: public-script-coord@w3.org
Message-Id: <E1RbP5m-0008CO-6d@jessica.w3.org>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=14877

--- Comment #24 from Cameron McCormack <cam@mcc.id.au> 2011-12-16 04:08:14 UTC ---
The reason I preferred "[object Node]" over "[object NodePrototype]" was for
the consistency with JS that Garrett pointed out.  For knowing what prototype
you're looking at, "[object Node]" seems sufficient, too.

OTOH, the reason that this is the case for JS builtins is because
String.prototype, RegExp.prototype, etc. are all actual String, RegExp, etc.
instances (differing only by their [[Prototype]] value).  In our case,
Node.prototype isn't an actual Node.

I see now (I wasn't reading closely enough before) that Garrett proposes this
for exception interface prototype objects, not necessarily interface prototype
objects in general, since it would be possible to have DOMException.prototype
be an actual DOMException instance (unlike Node, which is abstract).  I am not
sure if there is any concrete benefit from doing this, though.  I think we can
either have exceptions be consistent with interfaces or with builtin Errors.

So I guess I'm not really opposed to "[object NodePrototype]" and "[object
DOMExceptionPrototype]".

As for String(Node) == "function Node() { ... }", if people prefer that then
I'm happy with it.  That Chrome already does this gives me a small amount of
reassurance that it's safe.

-- 
Configure bugmail: https://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 Friday, 16 December 2011 04:08:23 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 May 2013 19:30:05 UTC