On Wed, Jul 31, 2013 at 10:50 AM, Mark S. Miller <erights at google.com> wrote:

>
>
>
> On Wed, Jul 31, 2013 at 6:24 AM, Dean Landolt <dean at deanlandolt.com>wrote:
>
>>
>>
>>
>> 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
>>
>
> Don't ever use MAC addresses, dates, times, positions, etc, as sources of
> uniqueness. What a collision resistant string? Use 128 bits of entropy.
> You'll get an accidental collision of these with the same rarity as you
> will for two unique symbols because of an undetected memory error.
>
>
>
>
>>  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.
>>
>
>
> ********************
>
> In thinking about this, I become ever more puzzled about the versioning
> and inter-realm problems for user-defined unique symbols -- I think it may
> be a train wreck. Scenario: Library W version 1.1 defines and uses a unique
> symbol @foo which is loaded into realm A. Library W version 1.2 purposely
> intends to continue to define and use the "same" unique symbol @foo, so
> that W1.2 code can successfully handle instances of W1.1 code. Library W1.2
> is loaded into realm B. The two realms come into contact, and objects from
> the two W's come into contact. *How did they both coordinate to define
> and use the same @foo symbol?*
>
> ********************
>


I responded in separate thread, but I'd add that this problem exists
regardless of the mechanism chosen for doing unique. It's not a problem of
symbols but of intrinsic object identity. This is why I believe modeling
symbols as stateless frozen objects is most sensible and correct thing.



> 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
>>
>
> That's why you refer to them symbolically. Just like we write Math.PI in
> good code, rather than 3.14159...
>


Agreed -- I was mostly joking. But there's a reason the proposal called for
a string prefix -- they will be reflected in the raw. Unlike Math.PI, this
raw value is meaningless.



>
>> 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 :)
>>
>
> This is the enumerability issue which I already acknowledged, right? Is
> there anything more to this?
>


I was responding directly to Kevin's comment:

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?


I was pointing out the very real hazard that exists in code which wouldn't
be considered objectively bad. To be explicit, I'm claiming that for/in
over object keys can be the Right Thing in cases where you want all
enumerable keys up through the prototype. If unique symbols aren't
enumerable *and* the platform demands any of them on Object.prototype this
will introduce subtle run-time breakages at least as badly as "null"
typeof. Even if es6 avoids them on Object.prototype who's to say they won't
be needed in later versions? This will bite eventually.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130731/a74b7b23/attachment-0001.html>

On Wed, Jul 31, 2013 at 10:50 AM, Mark S. Miller <erights at google.com> wrote:

> In thinking about this, I become ever more puzzled about the versioning
> and inter-realm problems for user-defined unique symbols -- I think it may
> be a train wreck. Scenario: Library W version 1.1 defines and uses a unique
> symbol @foo which is loaded into realm A. Library W version 1.2 purposely
> intends to continue to define and use the "same" unique symbol @foo, so
> that W1.2 code can successfully handle instances of W1.1 code. Library W1.2
> is loaded into realm B. The two realms come into contact, and objects from
> the two W's come into contact. *How did they both coordinate to define
> and use the same @foo symbol?*

I responded in separate thread, but I'd add that this problem exists
regardless of the mechanism chosen for doing unique. It's not a problem of
symbols but of intrinsic object identity. This is why I believe modeling
symbols as stateless frozen objects is most sensible and correct thing.

> That's why you refer to them symbolically. Just like we write Math.PI in good code, rather than 3.14159...


Agreed -- I was mostly joking. But there's a reason the proposal called for
a string prefix -- they will be reflected in the raw. Unlike Math.PI, this
raw value is meaningless.

> This is the enumerability issue which I already acknowledged, right? Is there anything more to this?


I was responding directly to Kevin's comment:

> 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?


I was pointing out the very real hazard that exists in code which wouldn't
be considered objectively bad. To be explicit, I'm claiming that for/in
over object keys can be the Right Thing in cases where you want all
enumerable keys up through the prototype. If unique symbols aren't
enumerable *and* the platform demands any of them on Object.prototype this
will introduce subtle run-time breakages at least as badly as "null"
typeof. Even if es6 avoids them on Object.prototype who's to say they won't
be needed in later versions? This will bite eventually.