typeof symbol (Was: Sept 19 TC39 Meeting Notes)
waldron.rick at gmail.com
Sat Sep 29 11:14:33 PDT 2012
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
> - 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
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
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
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss