typeof symbol (Was: Sept 19 TC39 Meeting Notes)

[Rick Waldron]

On Sat, Sep 29, 2012 at 9:34 AM, Herby Vojčík <herby at mailbox.sk> wrote:

>
>
> Tom Van Cutsem wrote:
>
>> 2012/9/29 Andreas Rossberg <rossberg at google.com
>> <mailto:rossberg at google.com>>
>>
>>
>>     On 28 September 2012 18:28, Tom Van Cutsem <tomvc.be at gmail.com
>>     <mailto:tomvc.be at gmail.com>> wrote:
>>      > I agree that proxying a symbol is of little value, but I didn't
>>     say that
>>      > symbols are closer to strings than to objects. I think symbols
>>     are closer to
>>      > objects: they have an unforgeable identity. Strings don't have
>>     that, objects
>>      > do.
>>
>>     I don't follow how generative creation is synonym to "identity", nor
>>     how identity implies being an object. Should we make everything an
>>     object just because we can? For symbols in particular I completely
>>     fail to see a good reason for doing so (now that we are able to drop
>>     the "public" name property). It will just induce extra cost for
>>     dubious semantic value -- or actually, semantic cost, as the issue of
>>     proxying them indicates.
>>
>>
>> I'm not against thinking of symbols as an entirely new "class" of
>> values. I was mostly arguing against the idea of having typeof symbol be
>> "string". If there are good reasons for symbols not to get their own
>> typeof type, I just think "object" would be more reasonable than "string".
>>
>
> When I though of this (from the user PoV), it seems to me that in fact,
> symbols _are_ closer to strings. I see it this way:
>
>   - closer to object === "symbol have its own identity, state and
> behaviour, I can add new properties and methods etc." (an array is good
> example of this, if you consider what it can do _beyond_ elements and
> length)
>   - close to string === "symbol have its own identity and a little more
> than that"
>
> IOW, it seems to me that symbols are more like "parallel" set of strings,
> of which every new one is different ("has different sequence of chars"),
> but it does not carry all the other "object-like" traits with it. More or
> less, only things that matters if if a symbol a === a symbol b. Which I see
> as string-like, not an object-like.
>
> But, again, this is less technical and more feeling.
>

Yes, there are certainly a number of both objective and
subjective arguments that could be had about this topic.

If Symbol does not have the built-in String prototype object as its
[[Prototype]] or in its chain, then typeof symbol should not return
"string".

The private name objects proposal specifies that Symbol (as Name)
properties will be treated differently then string properties and even
describes a new internal operation to supplant ToString's role in property
lookup[0].

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




Rick


[0] http://wiki.ecmascript.org/doku.php?id=harmony:private_name_objects








>
> Herby
>
>>
>> Cheers,
>> Tom
>>
> ______________________________**_________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120929/fe111cac/attachment.html>