@@toStringTag spoofing for null and undefined

Allen Wirfs-Brock allen at wirfs-brock.com
Wed Jan 21 08:32:41 PST 2015

On Jan 20, 2015, at 9:42 PM, Brendan Eich wrote:

> Mark S. Miller wrote:
>> Good, I understand now. I agree with all this. In ES6 the common cases have to work right, and no guarantees compromised. Beyond the common cases, extensibility we're confident in is great now. Otherwise, place restriction where needed now (static and dynamic errors, inaccessible symbols) to make the world safe for the extensibility directions we think we are likely to want in the future.
>> No exposed @toStringTag in ES6. Not because this extension point could grow into an extensible branding mechanism (it can't), but because we're not yet clear on how to prevent it from being mistaken for one.
>> A fair summary?
> Fair. Allen?

It's a fair summary of where we were in the discussion last night.  But after having a night to stew on it, I've moved on and my current position is very similar to Domenic's.  I'll elaborate on that in a separate response.

There is no such thing as a symbol valued property key that is not exposed via reflection.  All properties keys are accessible via Object.getOwnPropertyKeys.  Here's all it takes to restore Symbol.toStringTag:

function restoreSymbolToStringTag(taggedObject) {
  //call this function with an object that is known to have a toStringTag value.  window might be a good candidate
  let symbolKeys = Object.getOwnPrpertyKeys(taggedObject);
  let desc = { }.toString.call(taggedObject);
  let tagMatch = /\[object (.*)]'.exec(desc);
  if (!tagMatch) return false;
  let observedTag = tagMatch[1];
  for (s of symbolKeys) {
      try {
           if (taggedObject[s]; === observedTag) {
               //found it!
               Synmbol.toStringTag = s;
               return true;
        } catch() {e) {};
     return false;  //not found

More information about the es-discuss mailing list