On Wed, Jul 31, 2013 at 10:50 AM, Mark S. Miller <erig...@google.com> wrote:
> > > > On Wed, Jul 31, 2013 at 6:24 AM, Dean Landolt <d...@deanlandolt.com>wrote: > >> >> >> >> On Wed, Jul 31, 2013 at 8:50 AM, Kevin Smith <zenpars...@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.
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
