On Fri, Jul 19, 2013 at 2:48 PM, Andreas Rossberg <[email protected]>wrote:
> On 19 July 2013 19:41, Dean Landolt <[email protected]> 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 completely agree that it makes sense to keep them as similar as possible to existing types. in fact, I'm just extending your argument a bit, but picking one nit: symbols are more like objects than strings. Since they're only useful as keys what matters for our purposes is their unique, unforgeable identity, which they share in common with any other object. The only thing they have in common specifically with strings (and not other primitives) is the special capability to act as an object key. But again, what matters here is *how* -- their intensional identity is crucially different than the extensional identity of strings. There's no reason I know of why this capability of being able to key an object property couldn't be extended from strings to objects -- provided, of course, that the objects are completely stateless and frozen. Isn't this the very definition of a Symbol? A symbol is just a stateless frozen object -- do we really care what it toString's to? Once an object is stateless and frozen it can't be anything but stateless and frozen, thus any stateless frozen object could just as well be a symbol. Sure, the language can spec a Symbol constructor to make it easier to mint stateless frozen objects, but is there any difference? So if your ends is to keep symbols as close as possible to existing types I think suspect this approach does you one better -- it makes Symbols a perfect subtype of one of the built-ins -- just not the one you were thinking :) > 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. > Perhaps. I know it'd be breaking -- perhaps I'm not being imaginative enough about the kind of code it could break. I doubt I've written code that would break on this, but I've *definitely* written code that will break if the range from typeof is expended. Regardless, I doubt it'd even be useful to hack the spec for a special toString. Is there any reason a symbol's toString couldn't return "[object Object]"? if this is the only drawback to normalizing symbols in the way I suggest, it seems like a small price when all the other quibbles being debated melt away.
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
