typeof symbol (Was: Sept 19 TC39 Meeting Notes)

[Rick Waldron]

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
> deal-killer.
>
> Between "object" and a new typeof result, "symbol", the safer course is
> "object".
>
> 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
> possible.


Half way there :) The proposal describes them as "deeply frozen"

Rick



>
>
> /be
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120929/69276d65/attachment.html>