On Fri, Jul 19, 2013 at 1:48 PM, Andreas Rossberg <rossb...@google.com> wrote: > On 19 July 2013 19:41, Dean Landolt <d...@deanlandolt.com> wrote: >> I'm curious how symbols differ semantically from null-prototype, empty, >> frozen objects? > > They differ in that the extra cruft that's needed to represent random > objects is a complete waste of space on them. Also, there is a > performance benefit if they can share a common representation with > strings, so that you don't need a case distinction in every place > dealing with property names (e.g. wrt to hashing). > > In any case, I don't want to focus exclusively on the implementation. > I also think that there are obvious semantic and usability reasons for > making them as similar to existing types as possible (esp strings, > which they are closely related to). > >> I can't think of any substantive differences other the power >> to act as object keys (and some seemingly insignificant details like >> toString behavior). If that's truly the case, wouldn't it be a lot easier to >> just allow any null-prototype, empty, frozen object to have the object-key >> capability? > > Unfortunately, making other objects into keys would break existing > code that assumes a ToString conversion for those.
Thus Dean's suggestion of only allowing it for null-prototype, frozen, empty objects. These are exceedingly rare in the first place, because you have to jump through several hoops to create them. (I don't think I like Dean's suggestion, but I don't want incorrect assumptions getting thrown about.) ~TJ _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
