No Reflect[Symbol.toStringTag] ?

[webbedspace]

I just noticed that some care has been taken into giving each of the new ES2015 built-ins an appropriate toStringTag (Map, Set, Symbol, generators, various iterators) as well as legacy non-callable objects (Math, JSON). However, Reflect isn't included. Do you think a Reflect[Symbol.toStringTag] of "Reflect" should be included for consistency with the other two non-callables?

[allenwb]

No, this was intentional decision.

Prior to ES5 the only namespace-like object in ES was the Math object. For reasons probably lost to history it was specified with a [[Class]] internal internal property whose value was "Math". In all other respects it was what we now call an ordinary object.

ES5 added the JSON object as a namespace object and we just followed the pattern established by Math.

ECMA-402 edition 1 introduce the Intl object as a name space object. It was just an ordinary object and was not specified to have a [[Class]] internal property. So, it would O.p.toString as "[object Object]".

ES6 eliminated [[Class]] because it was being wide misused, in conjunction with Object.prototype.toString to perform (often unnecessary or undesirable) pseudo nominal type checking. Instead we made O.p.toString extensible via the @@toStringTag property. For backwards compatibility, we changed O.p.toString such that all the truly exotic objects from ES5 were detectable within toString such that their legacy toString value was maintained. That left Math and JSON (which in ES6 are just ordinary objects) as the only legacy ordinary objects that had special legacy O.p.toString behavior. We used the @@toStringTag mechanism to make their O.p.toString behavior backwards compatible.

For new ES6 build-in "classes" (Promise, Map, Set, Float32Array, etc.) we provided a @@toStringTag method on their prototype objects such that the instances of those classes would be identified as such by O.p.toString.

Reflect isn't a "class", it is just namespace defined using an ordinary object. Such name space objects are now widely used in JS code and typically don't have custom toString behavior. So we followed the precedent of ECMA-402 Intl and did not give Reflect its own @@toStringTag

Part of the motivation, was a desire during ES6 that we should minimize the specialness of builtins. In general, we wanted built-ins to be as much as possible just ordinary objects that might be implemented by everyday JS programmers and hence the builtins should generally follow the same conventions as we expect ordinary JS programmers to follow. For the class-like buildins we established a new convention of using @@tostring on the prototype to name class instances. Hopefully that is a convention that will catch on with JS programmers. For namespace objects like Reflect we expect JS programmers to continue to use direct object instance (often constructed via object literals) and that they typically won't give them unique @@toStringTag properties. So most name spaces including Intl and Reflect will print as "[object Object]".

[allenwb]

No, this was intentional decision.

Prior to ES5 the only namespace-like object in ES was the Math object. For reasons probably lost to history it was specified with a [[Class]] internal internal property whose value was "Math". In all other respects it was what we now call an ordinary object.

ES5 added the JSON object as a namespace object and we just followed the pattern established by Math.

ECMA-402 edition 1 introduce the Intl object as a name space object. It was just an ordinary object and was not specified to have a [[Class]] internal property. So, it would O.p.toString as "[object Object]".

ES6 eliminated [[Class]] because it was being wide misused, in conjunction with Object.prototype.toString to perform (often unnecessary or undesirable) pseudo nominal type checking. Instead we made O.p.toString extensible via the @@toStringTag property. For backwards compatibility, we changed O.p.toString such that all the truly exotic objects from ES5 were detectable within toString such that their legacy toString value was maintained. That left Math and JSON (which in ES6 are just ordinary objects) as the only legacy ordinary objects that had special legacy O.p.toString behavior. We used the @@toStringTag mechanism to make their O.p.toString behavior backwards compatible.

For new ES6 build-in "classes" (Promise, Map, Set, Float32Array, etc.) we provided a @@toStringTag method on their prototype objects such that the instances of those classes would be identified as such by O.p.toString.

Reflect isn't a "class", it is just namespace defined using an ordinary object. Such name space objects are now widely used in JS code and typically don't have custom toString behavior. So we followed the precedent of ECMA-402 Intl and did not give Reflect its own @@toStringTag

Part of the motivation, was a desire during ES6 that we should minimize the specialness of builtins. In general, we wanted built-ins to be as much as possible just ordinary objects that might be implemented by everyday JS programmers and hence the builtins should generally follow the same conventions as we expect ordinary JS programmers to follow. For the class-like buildins we established a new convention of using @@tostring on the prototype to name class instances. Hopefully that is a convention that will catch on with JS programmers. For namespace objects like Reflect we expect JS programmers to continue to use direct object instance (often constructed via object literals) and that they typically won't give them unique @@toStringTag properties. So most name spaces including Intl and Reflect will print as "[object Object]".

[bterlson]

Agree with Allen. No need to make Reflect special. Consistency argument doesn't seem strong.

[bterlson]

Agree with Allen. No need to make Reflect special. Consistency argument doesn't seem strong.