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'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...



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


-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130731/2c9101c9/attachment.html>

On Wed, Jul 31, 2013 at 6:24 AM, Dean Landolt <dean at deanlandolt.com> wrote:

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

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



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