Configurability of @@toStringTag for Built-ins

Allen Wirfs-Brock allen at wirfs-brock.com
Tue Dec 16 12:09:49 PST 2014


On Dec 16, 2014, at 10:49 AM, Rick Waldron wrote:

> Allowing configurability of the value of a built-in object's @@toStringTag property has the (likely undesirable) side effect of making calls to Object.prototype.toString.call(o) unreliable. 
> 
> Illustrated here: https://twitter.com/caitp88/status/525700685942509569
> 
> Repeated here for the purpose of discussion: 
> 
>   Object.prototype.toString.call(new Map());
>   "[object Map]"
>   Object.defineProperty(Map.prototype, Symbol.toStringTag, { value: "Fish" });
>   // ...
>   Object.prototype.toString.call(new Map());
>   "[object Fish]"
> 
> While this won't break existing code (see: https://people.mozilla.org/~jorendorff/es6-draft.html#sec-object.prototype.tostring), there should be consistency across built-ins. I propose we adopt as a rule that the @@toStringTag for all _built-ins_ is always defined as: 
> 
> { [[Writable]]: false, [[Enumerable]]: false, [[Configurable]]: false }
> 

The @@toStrngTag mechanism is, by design, unreliable for non-legacy built-ins.  TC39 decided that the legacy use of O.p.toString as a normative type test for built-ins was a practice we wanted support moving forward beyond ES5. 

Why do you think there should be consistency across built-ins? What about consistency between built-ins and ES defined classes? 

Allen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20141216/8134f5a5/attachment.html>


More information about the es-discuss mailing list