On Sat, Sep 29, 2012 at 11:52 AM, Brendan Eich <[email protected]> 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 > > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
