- From: <bugzilla@jessica.w3.org>
- Date: Mon, 21 Nov 2011 17:55:45 +0000
- To: public-script-coord@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14877 --- Comment #9 from David Flanagan <dflanagan@mozilla.com> 2011-11-21 17:55:43 UTC --- (In reply to comment #5) > (In reply to comment #4) > > Of course, WebIDL already has [[Class]] and other requirements that are > > impossible to conform to in ES5 implementations. > > Right, we've already crossed the bridge into ES5+proxies land. I am not > strongly disposed in either direction, but if we do choose something related to > the interface name, it should "<Interface>Prototype" makes sense to me. Right, but even with proxies, we still can't specify [[Class]] for arbitrary objects. (In reply to comment #6) > You can mostly fake it by adding a custom toString, no? That doesn't work if > someone uses Object.prototype.toString, but it works for alert(). The method would have to check the value of this to see if it was being called on the prototype or on an instance and return a different string in each case. But defining a toString() method on the prototype object would itself be a violation of WebIDL; possibly a worse violation than the [[Class]] violation. And I can't put it on a prototype object higher up the inheritance chain, since WebIDL doesn't allow that, either. But you tangentially raise an interesting question. Instead of having WebIDL standardize the ES-internal [[Class]] attribute, how about having it standardize the behavior of toString() on the objects it defines? -- 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 17:55:47 UTC