@@toStringTag spoofing for null and undefined

Mark Miller erights at gmail.com
Wed Jan 21 13:10:55 PST 2015


On Wed, Jan 21, 2015 at 1:05 PM, Jordan Harband <ljharb at gmail.com> wrote:

> > Just checking: Are we talking about adding it to each instance as a
> non-configurable non-writable data property?
>
> Mark: No, not to each instance, but to Array.prototype,
> Function.prototype, etc. If someone wants to override it on a specific
> instance that's fine, and I don't think it's important to protect against
> that.
>

In that case, I find this unacceptable, as it breaks the branding invariant
that some legacy ES5 code depends on.



>
> > I would not be happy with making the built-ins nonconfigurable. Just
> like Function.prototype.length, it should be unlocked.
>
> Domenic: Changing Function#length makes sense to me - the Function#bind
> shim does nasty things to ensure "length" is set properly, for example, and
> it would be much easier if the length was editable. Do you have a use case
> in mind where you'd want to change a language builtins' @@toStringTag value?
>
> We can always unlock it later, but it seems like we can't lock it down
> once it's unlocked, so without any valid use cases, it seems like a risky
> move to unlock it now.
>
> On Wed, Jan 21, 2015 at 1:00 PM, Mark S. Miller <erights at google.com>
> wrote:
>
>> On Wed, Jan 21, 2015 at 12:57 PM, Mark Miller <erights at gmail.com> wrote:
>> [...]
>>
>>> 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
>>> unconfigurable?
>>>
>>
>> Sorry, incomplete question. Meant:
>>
>> Just checking: Are we talking about adding it to each instance as a
>> non-configurable non-writable data property?
>>
>>
>> --
>>     Cheers,
>>     --MarkM
>>
>
>


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


More information about the es-discuss mailing list