Re-forking a bit to discuss not the output of "typeof aSymbol", but rather
the spec type (like ES5.1 - 8.x sections) of symbols.
Although we can discuss whether typeof should return "object", it's clear
to me that symbols aren't quite Objects (as per ES5.1 - 8.6). So far, they
have no reason to have a [[Prototype]], in all likelihood, since .public
seems gone, symbols won't need properties. Since there are no properties,
it's unclear what the necessity of internal methods is. There is no need
for [[extensible]] either.
So I guess a new 8.x section need to be added for symbols?
Hi,
Re-forking a bit to discuss not the output of "typeof aSymbol", but rather
the spec type (like ES5.1 - 8.x sections) of symbols.
Although we can discuss whether typeof should return "object", it's clear
to me that symbols aren't quite Objects (as per ES5.1 - 8.6). So far, they
have no reason to have a [[Prototype]], in all likelihood, since .public
seems gone, symbols won't need properties. Since there are no properties,
it's unclear what the necessity of internal methods is. There is no need
for [[extensible]] either.
So I guess a new 8.x section need to be added for symbols?
David
2012/9/29 Tom Van Cutsem <tomvc.be at gmail.com>
> 2012/9/29 Andreas Rossberg <rossberg at google.com>
>
>> On 28 September 2012 18:28, Tom Van Cutsem <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".
>
> Cheers,
> Tom
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121001/d317c8e0/attachment-0001.html>
Re-forking a bit to discuss not the output of "typeof aSymbol", but rather the spec type (like ES5.1 - 8.x sections) of symbols. Although we can discuss whether typeof should return "object", it's clear to me that symbols aren't quite Objects (as per ES5.1 - 8.6). So far, they have no reason to have a [[Prototype]], in all likelihood, since .public seems gone, symbols won't need properties. Since there are no properties, it's unclear what the necessity of internal methods is. There is no need for [[extensible]] either. So I guess a new 8.x section need to be added for symbols?
David
2012/9/29 Tom Van Cutsem <tomvc.be at gmail.com>