@@toStringTag spoofing for null and undefined

[Domenic Denicola]

From: Brendan Eich [mailto:brendan at mozilla.org] 

> Can we get a leg up, rather than wait for a f2f? This thread seems fine for further discussion and simplifying proposals.

Well, to be clear, I'd prefer we not change anything at all. It's too late to be tweaking something that's been set in the spec for a very long time now.

But it appears that we have some relitigation on this particular topic [on the agenda anyway][1]:

>  @@toStringTag (rationales) (Jordan Harband)
>
> - Missing unspoofable builtin values (Math, JSON, Object): spec bug
> - Should built-in @@toStringTag values have { configurable: false }?
> - Should Object.prototype.toString add a prefix to all non-built-in @@toStringTag values?

It seems the "protections" in the spec so far have given some the misleading impression that we want to encourage O.p.toString as an unspoofable [[Class]] test. (Not that [[Class]] even exists anymore!) But as Allen points out, that's not the idea at all. And I'm loathe to perpetuate that usage of them---or even the impression that they should be used that way. (Nominal-typing bad! Especially in ES6/ES7/etc. where proxies/value types/etc. give us the ability to perfectly emulate the characteristics of those types!)

So if we're going to have some kind of debate about @@toStringTag anyway, I plan to be representing the side that thinks we shouldn't be protecting anything, and should just dumb it down to a simple double-dispatch protocol.

[1]: https://github.com/tc39/agendas/blob/master/2015/01.md