Add String.prototype[@@toStringTag] and other pre-ES6 constructors' toStringTag property

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Add String.prototype[@@toStringTag] and other pre-ES6 constructors' toStringTag property

Gary Guo
By letting
Array.prototype[@@toStringTag] = 'Array',
String.prototype[@@toStringTag] = 'String',
Function.prototype[@@toStringTag] = 'Function',
Error.prototype[@@toStringTag] = 'Error',
Boolean.prototype[@@toStringTag] = 'Boolean',
Number.prototype[@@toStringTag] = 'Number',
Date.prototype[@@toStringTag] = 'Date',
RegExp.prototype[@@toStringTag] = 'RegExp,
we are able to simplify Object.prototype.toString's algorithm and make constructor.prototype[@@toStringTag] more consistent.

What's more, it can also preserve compatibility for pre-ES6 codes, since most prototypes are now ordinary objects.
In ES5:
Object.prototype.toString.call(String.prototype) == '[object String]'
In current ES6 spec:
Object.prototype.toString.call(String.prototype) == '[object Object]'
After my proposal:
Object.prototype.toString.call(String.prototype) == '[object String]'

Reported as https://bugs.ecmascript.org/show_bug.cgi?id=3857

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Add String.prototype[@@toStringTag] and other pre-ES6 constructors' toStringTag property

Jordan Harband
Hi Gary - the problem with this suggestion, is that in ES6 those prototypes are *not* exotic objects. So, setting @@toStringTag on `Boolean.prototype`, for example, would send `Boolean.prototype` itself down a legacy code path that might depend on an internal slot on a Boolean object, say, `Boolean.prototype.valueOf.call` (and the same for all the others).

I think that the only way that Object#toString.call should return "X" by default is if the item is actually a X, which X.prototype no longer is (for the values of X in question).

On Fri, Feb 13, 2015 at 8:09 PM, Gary Guo <[hidden email]> wrote:
By letting
Array.prototype[@@toStringTag] = 'Array',
String.prototype[@@toStringTag] = 'String',
Function.prototype[@@toStringTag] = 'Function',
Error.prototype[@@toStringTag] = 'Error',
Boolean.prototype[@@toStringTag] = 'Boolean',
Number.prototype[@@toStringTag] = 'Number',
Date.prototype[@@toStringTag] = 'Date',
RegExp.prototype[@@toStringTag] = 'RegExp,
we are able to simplify Object.prototype.toString's algorithm and make constructor.prototype[@@toStringTag] more consistent.

What's more, it can also preserve compatibility for pre-ES6 codes, since most prototypes are now ordinary objects.
In ES5:
Object.prototype.toString.call(String.prototype) == '[object String]'
In current ES6 spec:
Object.prototype.toString.call(String.prototype) == '[object Object]'
After my proposal:
Object.prototype.toString.call(String.prototype) == '[object String]'

Reported as https://bugs.ecmascript.org/show_bug.cgi?id=3857

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

RE: Add String.prototype[@@toStringTag] and other pre-ES6 constructors' toStringTag property

Gary Guo
Yes, I know it's true. But according to editors, they don't see usage of these prototypes as exotic objects, so they change them to ordinary objects. Since they are hardly used as exotic objects, I think it will be proper to set @@toStringTag on them.

BTW, according to Allen, the spec about @@toStringTag is settled, it seems that this proposal will never be the case.


From: [hidden email]
Date: Tue, 17 Feb 2015 15:53:21 -0800
Subject: Re: Add String.prototype[@@toStringTag] and other pre-ES6 constructors' toStringTag property
To: [hidden email]
CC: [hidden email]

Hi Gary - the problem with this suggestion, is that in ES6 those prototypes are *not* exotic objects. So, setting @@toStringTag on `Boolean.prototype`, for example, would send `Boolean.prototype` itself down a legacy code path that might depend on an internal slot on a Boolean object, say, `Boolean.prototype.valueOf.call` (and the same for all the others).

I think that the only way that Object#toString.call should return "X" by default is if the item is actually a X, which X.prototype no longer is (for the values of X in question).

On Fri, Feb 13, 2015 at 8:09 PM, Gary Guo <[hidden email]> wrote:
By letting
Array.prototype[@@toStringTag] = 'Array',
String.prototype[@@toStringTag] = 'String',
Function.prototype[@@toStringTag] = 'Function',
Error.prototype[@@toStringTag] = 'Error',
Boolean.prototype[@@toStringTag] = 'Boolean',
Number.prototype[@@toStringTag] = 'Number',
Date.prototype[@@toStringTag] = 'Date',
RegExp.prototype[@@toStringTag] = 'RegExp,
we are able to simplify Object.prototype.toString's algorithm and make constructor.prototype[@@toStringTag] more consistent.

What's more, it can also preserve compatibility for pre-ES6 codes, since most prototypes are now ordinary objects.
In ES5:
Object.prototype.toString.call(String.prototype) == '[object String]'
In current ES6 spec:
Object.prototype.toString.call(String.prototype) == '[object Object]'
After my proposal:
Object.prototype.toString.call(String.prototype) == '[object String]'

Reported as https://bugs.ecmascript.org/show_bug.cgi?id=3857

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss