Intent to Implement Symbol.toStringTag in V8

[Caitlin Potter]

The well-known Symbol.toStringTag and its related changes in Object.prototype.toString --- is a stable API introduced in ECMA-262 6th edition draft from September 27, 2012, and has apparently not changed since its inception. The goal is to mitigate the use of Object.prototype.toString as a way of getting the [[Class]] value of an object [1, 2], and to provide a way to illustrate an object's type, which may be useful for dev tools.

I'd like to put this behind a flag --- not exposing Symbol.toStringTag until the semantics in O.p.toString are also available.

There are a number of bugs fixed by this, including v8:3502, v8:3241, v8:3619

Design Doc / Patch

https://crrev.com/546803003/

Other implementations

There are no other implementations currently. There is not currently a bug to implement on SpiderMonkey, nor JSC.

Technical considerations

None, It's a very simple feature.

Perf Considerations

It is likely that this will slow down Object.prototype.toString to some degree, but it's not clear how much of a hot spot O.p.toString really is in a typical application.

[1] https://github.com/rwaldron/tc39-notes/blob/master/es6/2012-07/july-24.md

[2] https://mail.mozilla.org/pipermail/es-discuss/2013-May/030699.html

[Dmitry Lomov]

LGTM

--
--
v8-users mailing list
v8-u...@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to the Google Groups "v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Isiah Meadows]

Outside of strings, numbers, and O.p.toString.call(foo), the rest of the use cases are exceptionally rare AFAIK.

[Erik Arvidsson]

LGTM

On Mon, Oct 20, 2014 at 8:56 AM, Isiah Meadows <impi...@gmail.com> wrote:

Outside of strings, numbers, and O.p.toString.call(foo), the rest of the use cases are exceptionally rare AFAIK.

Not sure what you mean here?

O.p.toString is very common. Lots of web code depends on it to detect what kind of object they have.

An implementation has to cover all bases, no matter how rare they are.

--
--
v8-users mailing list
v8-u...@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to the Google Groups "v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
erik

[Isiah Meadows]

I was talking about special cases that can be optimized, but the uncommon use case would be more of a code smell than anything else, `string + new MyClass()`. I'm well aware of the common use of O.p.toString in type detection.

I mistook the {Number,String}.p.toString as part of O.p.toString. That was the core of the ambiguity/stupidity on my part.

I would say that the JIT may be able to use branch prediction and get around that problem to a large extent.

On a side note, it may become common and suggested practice to declare a @@toStringTag for all exported classes.