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, 09 Dec 2011 05:52:34 +0000
To: public-script-coord@w3.org
Message-Id: <E1RYtNq-00089E-TK@jessica.w3.org>

--- Comment #20 from Cameron McCormack <cam@mcc.id.au> 2011-12-09 05:52:33 UTC ---
(In reply to comment #19)
> Current WebIDL depends on ES5.  In ES5, we have no way to affect toString
> except via [[Class]], which we're explicitly allowed to define for host objects
> (see comment #14, first quote).  If ES6 gets rid of [[Class]] and gives some
> other mechanism for affecting .toString, then we can change WebIDL at that
> point.  But for now, we only have ES5, and we have to work with its definition
> of .toString.  There is no way to futureproof this -- if ES6 gets rid of
> [[Class]], we need to just update WebIDL then.

We have already defined [[Class]] to be something host object-y for actual
instances of Node etc., even though Proxies don't let us specify that.  It's no
worse to extend this to interface prototype objects, etc.

It's not an uncommon pattern for script to do
Object.prototype.toString.call(obj) and then extract out the bit between the
"[object " and "]".  For this, simply overriding toString on
HTMLDivElement.prototype isn't going to cut it.

What if we *cough* have Web IDL say that as soon as an ECMAScript environment
is created, that Object.prototype.toString is overridden with something that
makes it look like HTMLDivElements have [[Class]] == "HTMLDivElement"?

That, or proxies need to gain the ability to not necessarily fake [[Class]],
but to affect what Object.prototype.toString returns.

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, 9 December 2011 05:52:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:05 UTC