Interface prototype objects and ES6 @@toStringTag
erik.arvidsson at gmail.com
Mon May 13 14:44:08 PDT 2013
Kevin: Node.prototype.toString is never invoked when you do
I understand that no one has complained. Browser differ in this area today
so applications have to be careful of they ever try to get the [[Class]] of
On Mon, May 13, 2013 at 5:12 PM, Kevin Reid <kpreid at google.com> wrote:
> On Mon, May 13, 2013 at 2:01 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote:
>> On May 13, 2013, at 1:50 PM, Erik Arvidsson wrote:
>> The way that WebIDL require Object.prototype.toString to return "[object
>> TypePrototype]" for the interface prototype object and "[object Type]" for
>> the instances seems to imply that every instance needs to have an own
>> If an instance does not have its own @@toStringTag,
>> Object.prototype.toString will read through to the [[Prototype]] which
>> would return the wrong string.
>> Well, toString just does a [[Get]] for @@toStringTag. You are perfectly
>> free to implement it as a get accessor that takes into account whether the
>> this value is an instance or a prototype object. Not sure whether the
>> complexity is really worth it in most cases. I considered building
>> something like that into Object.prototype.toString but it seemed hard to
>> justify and there was no (ES) legacy reason for doing so.
>> The preferred way to over-ride toString should be via a toString method,
>> not via @@toStringTag.
> FWIW, oddball implementor's experience:
> In Caja's emulated DOM type hierarchy, Node.prototype.toString is an
> ordinary method which searches the prototype chain for the appropriate
> type-name, including distinguishing prototypes. This seems to work fine
> insofar as it gives the answers I want it to give and nobody's ever
> complained, and I think it's identical in abilities and effects to your
> proposal of an @@toStringTag accessor.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss