Mark S. Miller wrote:
Regarding the integrity of original Object.prototype.toString.call as
a branding mechanism, I agree we need a new more general branding
mechanism. WeakMaps and Symbols both give us a place to hang this, but
we need a concrete proposal. The proposal should work both with
builtins and with classes. If a better branding proposal waits till
ES7, then we need to preserve integrity of original
Object.prototype.toString.call as a branding mechanism through ES6. If
this is preserved through ES6, then it probably
becomes too entrenched to consider retiring.
Were there other questions for me that I missed?
Yes. Should (per the latest draft, 15.2.4.2 Object.prototype.toString)
the following names:
"Arguments", "Array", "Boolean", "Date", "Error", "Function", "JSON",
"Math", "Number", "Object", "RegExp", or "String"
and "Object" (per Allen here), and only these names, be prefixed with
"~" when returned via [[Get]](@@toStringTag) where @@toStringTag denotes
a spec-internal (implementation-internal) symbol?
The idea is to uphold ES5's paragraph from Clause 15, starting
''The value of the [[Class]] internal property is defined by this
specification for every kind of built-in object. The
value of the [[Class]] internal property of a host object may be any
String value except one of "Arguments",
"Array", "Boolean", "Date", "Error", "Function", "JSON", "Math",
"Number", "Object",
"RegExp", and "String".''
Step 4 uses [[NativeBrand]] in preference to @@toStringTag, which
enables the core-language built-ins to return, e.g., "Array" without
fear of "~" being prepended.
This two-level scheme seems like overkill, and the clause 15 intro
restriction on host objects claiming, e.g., to be of "Function"
[[Class]] (presumably to be updated to [[NativeBrand]]) seems
unnecessary to me. If a host function satisfies all the observable
requirements of a native one, why not?
I asked a question aimed more directly at you up-thread: why should
*only* the above 12 or 13 names be subject to "~"-prepending when
returned from an object that lacks [[NativeBrand]]? Are there not host
objects in need of protection from class-spoofing?
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
