- From: <bugzilla@jessica.w3.org>
- Date: Fri, 09 Dec 2011 05:52:34 +0000
- To: public-script-coord@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=14877 --- 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