Interface prototype objects and ES6 @@toStringTag
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 @@toStringTag.
people.mozilla.org/~jorendorff/es6-draft.html#sec-15.2.4.2, dev.w3.org/2006/webapi/WebIDL/#es-environment
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.
On Mon, May 13, 2013 at 5:01 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote:
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.
OK. Something like this might work:
Object.defineProperty(Type.prototype, @@toStringTag, {
get: function() {
return 'Type' + (this === Type.prototype ? 'Prototype' : '');
}
});
This is of course observable if we expose @@toStringTag.
The preferred way to over-ride toString should be via a toString method, not via @@toStringTag.
Agreed, but WebIDL currently mandates the result of Object.prototype.toString.
On May 13, 2013, at 2:16 PM, Erik Arvidsson wrote:
OK. Something like this might work:
Object.defineProperty(Type.prototype, @@toStringTag, { get: function() { return 'Type' + (this === Type.prototype ? 'Prototype' : ''); } });This is of course observable if we expose @@toStringTag.
@@toStringTag is just a ES code accessible extension mechanism for Object.prototype.toString. Nobody ever claimed it wasn't observable.
The preferred way to over-ride toString should be via a toString method, not via @@toStringTag.
Agreed, but WebIDL currently mandates the result of Object.prototype.toString.
Maybe it shouldn't. Part of the motivation here is to start migrating people way from thinking that O.p.toString is a reliable brand test, particularly WRT to anything new that is created.
Kevin: Node.prototype.toString is never invoked when you do Object.prototype.toString.call(HTMLElement.prototype)
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 something.
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 @@toStringTag.
people.mozilla.org/~jorendorff/es6-draft.html#sec-15.2.4.2, dev.w3.org/2006/webapi/WebIDL/#es-environment
If an instance does not have its own @@toStringTag, Object.prototype.toString will read through to the [[Prototype]] which would return the wrong string.