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.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
