@@toStringTag spoofing for null and undefined

[Brendan Eich]

Allen Wirfs-Brock wrote:
> On Jan 21, 2015, at 9:34 AM, Brendan Eich wrote:
>
>> >  Allen Wirfs-Brock wrote:
>>> >>  There is no such thing as a symbol valued property key that is not exposed via reflection.
>> >  
>> >  Sure -- the idea was to make the symbol spec-internal, even use an abstract operation rather than a symbol -- anything to provide a spec hook for WHATWG/W3C specs to build on, without overcommitting.
>
> Then it's not a symbol at all.  It might as well be an internal slot on every objected named, for example, "[[Class]]".

Sure -- good point, I flinched and was slot to say "internal property" 
because we all don't like infernal slots. ;-)

>> >  Calling @@toStringTag a "solid win" is premature. We can extend in many ways to allow the platform to be explained better in self-hosted JS. That does not mean a configurable non-writable property, "~"-prefixing, the whitelist.
>
> I agree, that the anti-spoofing is the most questionable part of the design and I would be fine with loosing it. But is it really questionable enough that we can't live with what is specified.  What is the fatal flaw. What does it actually harm?

This is not the question to ask, since there won't be obvious fatal 
flaws in lots of things we still need to agree upon, yet the cumulative 
complexity will hide flaws. We need to reduce complexity to reduce risk 
of something bad (however non-fatal). Many small wounds add up. I know 
this too well from JS, which barely survived its early trials.

Let's lose what we can, to avoid letting loose the 
complexity/risk-hounds ;-). How would you cut anti-spoofing?

/be