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 <[email protected]> > 2012/9/29 Andreas Rossberg <[email protected]> > >> On 28 September 2012 18:28, Tom Van Cutsem <[email protected]> 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 >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
