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 <bren...@mozilla.org
<mailto:bren...@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
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
