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


Brendan Eich <brendan@mozilla.org> changed:

           What    |Removed                     |Added
                 CC|                            |allen@wirfs-brock.com,
                   |                            |brendan@mozilla.org,
                   |                            |bzbarsky@mit.edu,
                   |                            |erights@gmail.com

--- Comment #10 from Brendan Eich <brendan@mozilla.org> 2011-11-21 19:42:34 UTC ---
(In reply to comment #9)
> (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.

You mean for non-proxies? True, in those cases overriding toString may be

Also, it's important to say the role of [[Class]], since ES6 drafts remove that
internal property in favor of generic (class-independent) semantics, or else a
more precise and less over-loaded internal nominal tagging scheme. I'm assuming
here the issue is Object.prototype.toString.

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

Ok, hmm. Gecko does have custom toString IIRC. We should make WebIDL map to JS
without requiring proxies if there is no need other than the O.p.toString one.

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

This seems strictly better, all else equal.


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 19:42:41 UTC