On Sat, Sep 29, 2012 at 9:34 AM, Herby Vojčík <[email protected]> wrote:
> > > Tom Van Cutsem wrote: > >> 2012/9/29 Andreas Rossberg <[email protected] >> <mailto:[email protected]>> >> >> >> On 28 September 2012 18:28, Tom Van Cutsem <[email protected] >> <mailto:[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". >> > > When I though of this (from the user PoV), it seems to me that in fact, > symbols _are_ closer to strings. I see it this way: > > - closer to object === "symbol have its own identity, state and > behaviour, I can add new properties and methods etc." (an array is good > example of this, if you consider what it can do _beyond_ elements and > length) > - close to string === "symbol have its own identity and a little more > than that" > > IOW, it seems to me that symbols are more like "parallel" set of strings, > of which every new one is different ("has different sequence of chars"), > but it does not carry all the other "object-like" traits with it. More or > less, only things that matters if if a symbol a === a symbol b. Which I see > as string-like, not an object-like. > > But, again, this is less technical and more feeling. > Yes, there are certainly a number of both objective and subjective arguments that could be had about this topic. If Symbol does not have the built-in String prototype object as its [[Prototype]] or in its chain, then typeof symbol should not return "string". The private name objects proposal specifies that Symbol (as Name) properties will be treated differently then string properties and even describes a new internal operation to supplant ToString's role in property lookup[0]. Offline discussion with Dave that immediately identified a deal-breaker: if typeof symbol were "string", it would break ===. === for strings is based on their contents === for objects is based on their identity Rick [0] http://wiki.ecmascript.org/doku.php?id=harmony:private_name_objects > > Herby > >> >> Cheers, >> Tom >> > ______________________________**_________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss> >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
