On Wed, Jul 31, 2013 at 8:50 AM, Kevin Smith <zenparsing at gmail.com> wrote:

>
> Aside from this confinement issue, all other the advantages that unique
>> symbols have over unique-ish strings seem minor to me. The biggest is
>> default non-enumerability, when we're getting away (admittedly slowly) from
>> enumerability being significant anyway. IMO, if the only advantages of
>> unique symbols over unique-ish strings are these minor ones, then they
>> don't pull their weight.
>>
>>
> The fact that, in the context of *unique* symbols, the unforgability
> property of the symbol is pointless indicates to me that we might have a
> mixing of orthogonal concerns.
>


Unforgability is pointless, sure, but not so fast: as Brendan suggested at
a few days back re: MAC addresses and such, you can't ignore the difference
between collision-*proof* and collision-*resistant.* The difference is
identity -- object (and symbol) identity is intrinsic, string identity is
extrinsic. If we're talking about keys we're talking about identity -- this
is not at all orthagonal.

I'm not arguing that this is enough of a justification for symbols
(especially in lieu of privates), but we can't hand-wave this distinction
away -- it's essential.


That leaves default non-enumerability.  Consider the fact that object
> literal methods are enumerable.  Why should choosing a "unique name" as
> opposed to an identifier for a method have any bearing on enumerability?
>


Because GUID-unique-strings are ugly? /troll

I know there's still a ton of unguarded for/in over object keys. I'll admit
to using it from time to time -- it's the easiest way to pick up enumerable
prototype keys, and plenty safe -- so long as you zealously guard
Object.prototype.

I still see the occasional for/in over arrays that would fail hard, but
that's harder to defend :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130731/6e57d3cd/attachment.html>

On Wed, Jul 31, 2013 at 8:50 AM, Kevin Smith <zenparsing at gmail.com> wrote:

>> Aside from this confinement issue, all other the advantages that unique
>> symbols have over unique-ish strings seem minor to me. The biggest is
>> default non-enumerability, when we're getting away (admittedly slowly) from
>> enumerability being significant anyway. IMO, if the only advantages of
>> unique symbols over unique-ish strings are these minor ones, then they
>> don't pull their weight.
>
> The fact that, in the context of *unique* symbols, the unforgability
> property of the symbol is pointless indicates to me that we might have a
> mixing of orthogonal concerns.
>


Unforgability is pointless, sure, but not so fast: as Brendan suggested at
a few days back re: MAC addresses and such, you can't ignore the difference
between collision-*proof* and collision-*resistant.* The difference is
identity -- object (and symbol) identity is intrinsic, string identity is
extrinsic. If we're talking about keys we're talking about identity -- this
is not at all orthagonal.

I'm not arguing that this is enough of a justification for symbols
(especially in lieu of privates), but we can't hand-wave this distinction
away -- it's essential.


> That leaves default non-enumerability.  Consider the fact that object
> literal methods are enumerable.  Why should choosing a "unique name" as
> opposed to an identifier for a method have any bearing on enumerability?


Because GUID-unique-strings are ugly? /troll

I know there's still a ton of unguarded for/in over object keys. I'll admit
to using it from time to time -- it's the easiest way to pick up enumerable
prototype keys, and plenty safe -- so long as you zealously guard
Object.prototype.

I still see the occasional for/in over arrays that would fail hard, but
that's harder to defend :)