@@toStringTag spoofing for null and undefined
Jordan Harband
ljharb at gmail.com
Wed Jan 21 13:05:17 PST 2015
> 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.
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150121/398faa8b/attachment.html>
More information about the es-discuss
mailing list