@@toStringTag spoofing for null and undefined

[Domenic Denicola]

I would not be happy with making the built-ins nonconfigurable. Just like Function.prototype.length, it should be unlocked.
________________________________
From: Jordan Harband<mailto:ljharb at gmail.com>
Sent: ‎2015-‎01-‎21 15:52
To: Brendan Eich<mailto:brendan at mozilla.org>
Cc: es-discuss<mailto:es-discuss at mozilla.org>
Subject: Re: @@toStringTag spoofing for null and undefined

To reiterate, I see the issue as boiling down to two questions:
1) Should builtins have their @@toStringTag value configurable?
Can anyone provide a use case, or any value, to allowing this? If not, I think they should not be configurable. I'd be very interested to hear why it would aid debugging, or help Domenic's DOM concerns (which are totally valid and admirable), or help with extensibility?

2) Should non-builtin JS values be able to pretend to be builtins via spoofing @@toStringTag?
If the answer to (1) is "every builtin's @@toStringTag is not configurable" then I think I'm actually comfortable with a value explicitly pretending to be an Array, for example, and risking the consequences of doing that incorrectly. In this scenario, dropping the prefixing entirely makes sense to me.

However, if the answer to (1) is "builtins' @@toStringTag is configurable", then this question needs to be modified.

I see no need to drop @@toStringTag, and little need to keep the prefixing at all, if all builtins (not just ES5 ones) have a nonconfigurable @@toStringTag.

It also suddenly occurs to me that the ability to pretend to be a builtin will in fact be very useful to me, personally, for the es*-shims.

Is there anyone who wouldn't be happy with "all builtins' @@toStringTag is not configurable" and "drop the ~ prefixing completely"?

On Wed, Jan 21, 2015 at 11:05 AM, Brendan Eich <brendan at mozilla.org<mailto:brendan at mozilla.org>> wrote:
Brendan Eich wrote:
Sure -- good point, I flinched and was slot

"slow", lulz.

/be
to say "internal property" because we all don't like infernal slots. ;-)
_______________________________________________
es-discuss mailing list
es-discuss at mozilla.org<mailto:es-discuss at mozilla.org>
https://mail.mozilla.org/listinfo/es-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150121/59f7d5b0/attachment.html>