Type of symbols (was: typeof symbol (Was: Sept 19 TC39 Meeting Notes))
bruant.d at gmail.com
Mon Oct 1 06:38:06 PDT 2012
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?
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,
>> > 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".
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss