@@toStringTag spoofing for null and undefined

[Mark S. Miller]

Good, I understand now. I agree with all this. In ES6 the common cases have
to work right, and no guarantees compromised. Beyond the common cases,
extensibility we're confident in is great now. Otherwise, place restriction
where needed now (static and dynamic errors, inaccessible symbols) to make
the world safe for the extensibility directions we think we are likely to
want in the future.

No exposed @toStringTag in ES6. Not because this extension point could grow
into an extensible branding mechanism (it can't), but because we're not yet
clear on how to prevent it from being mistaken for one.

A fair summary?



On Tue, Jan 20, 2015 at 9:10 PM, Brendan Eich <brendan at mozilla.org> wrote:

> Mark S. Miller wrote:
>
>> I understood and agree with everything (or close enough) until your last:
>>
>> On Tue, Jan 20, 2015 at 7:20 PM, Brendan Eich <brendan at mozilla.org
>> <mailto:brendan at mozilla.org>> wrote:
>>
>>     ISTM we need more definite consensus on branding to finish off
>>     toStringTag in ES6.
>>
>>
>>
>> What we don't have is an inter-realm extensible branding mechanism.
>>
>> * typeof, Array.isArray, the ES5-compatible subset of O.p.toString.call's
>> behavior are inter-realm branding, but not extensible.
>>
>> * === and WeakMap provide extensible branding, but not in a way that is
>> usable inter-realm.
>>
>> * the rest of O.p.toString.call's behavior, i.e., the toStringTag
>> mechanism, is an inter-realm extensible labeling mechanism, but isn't a
>> branding mechanism.
>>
>>
>> Does the last bullet unask your question, or have I misunderstood?
>>
>
> Not sure what my question is, referenced in your last sentence. The call
> for more definite branding thinking for ES7 before we nail down toStringTag
> for ES6? That's not a question :-P.
>
> Anyway, toStringTag in draft ES6 is not a branding mechanism, but I agree
> with Jordan that this is a problem! People have been using
> O.p.toString.call for brand tests, whether we like it or not.
>
> Allen's right that we don't want to make things worse by paving a cowpath
> toward "bad branding", but is the ES6 draft's neither-fish-nor-fowl
> toStringTag situation truly better? I think not.
>
> Surgically removing toStringTag API surface is worth another look. We'd be
> no worse, ignoring the DOM and other specs that build on the core ECMA-262
> spec, than we were with ES5.
>
> Idea: we could let those other specs use @@toStringTag as an extension
> mechanism, but ES6 would not expose it to userland via Symbol.toStringTag,
> nor would ES6 do any "~"-prefixing. We'd rely on WHATWG and W3C spec
> authors to play nice and not spoof core built-in tag-names.
>
> What to do about `class MyArray extends Array {...}`, where one wants
> "[object MyArray]" from O.p.toString.call on an instance of MyArray? ES6
> class syntax could set @@toStringTag under the hood, another bit of magic
> for which no desugaring (in the Felleisen translation-not-compilation
> sense) yet exists, akin to super. Grist for the ES7 mill.
>
> This seems the safest play to me at the moment, and it gets rid of the
> prefixing and configurability issues, but not the whitelist. The whitelist
> rather becomes a blacklist of names that cause an early error, e.g. for
> `class Array {...}`. Errors are more future-friendly, especially early
> errors. We can perhaps relax some later.
>
> Would this be too restrictive, in terms of throwing on friendly mocks such
> as `class RegExp {...}` that wraps a bona fide JS regexp? Perhaps, but it
> still seems safer. We need to finish ES6 without overcommitting to, and
> over-specifying, stuff we may regret later.
>
> /be
>
>
>


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