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: Mon, 21 Nov 2011 17:55:45 +0000
To: public-script-coord@w3.org
Message-Id: <E1RSY5p-0006nn-1N@jessica.w3.org>

--- 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

(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

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