@@toStringTag spoofing for null and undefined

[Jordan Harband]

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> 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
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150121/9f29ce29/attachment.html>