How would object value types such as int64 work? Should symbols be similar?
On Apr 13, 2013, at 0:35 , Allen Wirfs-Brock <[email protected]> wrote: > > On Apr 12, 2013, at 3:12 PM, Brandon Benvie wrote: > >> Based on recent discussions, it seems that there's some confusion about what >> exactly Symbols are. So far I've seen three different alternatives: >> >> 1.) Exotic objects that conform to the most recent ES6 spec, but with a >> special typeof .That is, they have special operations for all the internal >> methods. These internal methods make them act as stateless, immutable, >> prototypeless objects such that they can be treated like primitives. The >> problem here is introducing new typeof semantics, where something that >> otherwise acts like an object is not typeof === "object". >> >> 2.) A new type of primitive that have no object wrapper version, thus >> `ToObject(symbol)` throws. This means either they have to be falsey or a new >> situation arises where `if (val != null) val.prop` throws (ignoring >> accessors and proxies). >> >> 3.) A new type of primitive along with a new type of wrapper. In this case >> we use the String/Number/Boolean precedent where `Symbol()` and `new >> Symbol()` produce different kinds of results. The problem here is the >> confusion that comes with ToString/ToPropertyKey when called on a Symbol >> wrapper. What does `obj[new Symbol] = 5` do, for example? It allows footguns >> like `obj[key + '_ext']` to silently do the wrong thing. >> >> >> A relevant gist here demonstrates test cases for option #1. I'll see if I >> can add comparable sets of tests for the other two options. [1] >> >> https://gist.github.com/Benvie/5375078 > > > there were lots of additional subtle points brought up on the twitter threads > > Regarding #1 > This is how it was spec. until the last TC39 meeting. > > Some implementers think this will be easiest to implement. > > Important point was that we probably don't want a new kind of "object" whose > typeof value is not "object". typeof is already confusing enough for objects > because of its handling of functions and null. We shouldn't make it worse > with typeof Symbol() == "symbol" yet symbols behave as objects. > > Regarding #2 > My comments in https://gist.github.com/Benvie/5375078#comment-815195 all > directly derive from the "normal" handling in the spec. of primitive values > or situations involving primitive values that don't have wrappers. > > Regarding #3 > > The biggest footgun is if > new Symbol() > creates a Symbol wrapper. However, > new Symbol() > returning a primitive values would be unlike anything we currently have in > the language > > I favor reverting to solution 1. > > Allen > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss -- Dr. Axel Rauschmayer [email protected] home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
