@@toStringTag spoofing for null and undefined
erights at gmail.com
Wed Jan 21 12:57:46 PST 2015
On Wed, Jan 21, 2015 at 12:51 PM, Jordan Harband <ljharb at gmail.com> wrote:
> 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"?
Just checking: Are we talking about adding it to each instance as
> On Wed, Jan 21, 2015 at 11:05 AM, Brendan Eich <brendan at mozilla.org>
>> Brendan Eich wrote:
>>> Sure -- good point, I flinched and was slot
>> "slow", lulz.
>>> to say "internal property" because we all don't like infernal slots. ;-)
>> es-discuss mailing list
>> es-discuss at mozilla.org
> es-discuss mailing list
> es-discuss at mozilla.org
Text by me above is hereby placed in the public domain
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss