typeof symbol (Was: Sept 19 TC39 Meeting Notes)
waldron.rick at gmail.com
Sat Sep 29 12:33:20 PDT 2012
On Sat, Sep 29, 2012 at 11:52 AM, Brendan Eich <brendan at mozilla.org> wrote:
> Rick Waldron wrote:
>> Offline discussion with Dave that immediately identified a deal-breaker:
>> if typeof symbol were "string", it would break ===.
>> === for strings is based on their contents
>> === for objects is based on their identity
> That's true but I think it has not to do with ===. It's because symbols
> must not be forgeable by spelling out any "contents" or "value" that can ==
> or === another symbol's contents/value.
> The invariant that applies:
> (typeof x == typeof y && x == y) <=> (x === y).
> This would hold even if typeof returned "string" for a symbol, so long as
> that symbol was == and === only itself.
> It obviously also works if typeof returns "object" for a symbol, as in the
> current proposal.
> In the sense that "abc" === "ab" + "c" then of course Dave's right. You
> can't do any such thing with a symbol. But so long as unforgeability is
> upheld, this issue is not about === (or ==). It's about typeof returning
> "string" for a symbol, a bad idea.
> The lack of String.prototype delegation as if by auto-wrapping is a second
> Between "object" and a new typeof result, "symbol", the safer course is
> For value objects such as int64 and uint64, I've come to believe that the
> invariant above conjoined with
> (0L == 0UL) === true
> being the desirable == but not === behavior requires typeof 0L => "int64"
> and typeof 0UL => "uint64.
> Value objects have content-based identity, but they're objects. Symbols
> could be viewed as objects and identity and typeof all work "for free".
> To resolve Andreas's concern about cost of object, we could say that
> Symbols are frozen and empty. That would be enough to optimize as hard as
Half way there :) The proposal describes them as "deeply frozen"
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss