How would object value types such as int64 work? Should symbols be similar?
On Apr 13, 2013, at 0:35 , Allen Wirfs-Brock <allen at wirfs-brock.com> 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
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
--
Dr. Axel Rauschmayer
axel at rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130413/4189a4b4/attachment.html>
github at esdiscuss.org (2013-07-12T02:27:01.855Z)
How would object value types such as `int64` work? Should symbols be similar?
