for what is worth it, this worked quite well in a single realm with no
enumerability though:
https://gist.github.com/WebReflection/5238782#file-gistfile1-js-L1
// example
var sym = new Symbol;
var o = {};
o[sym] = 123;
console.log(o[sym]);
On Wed, Jul 31, 2013 at 10:49 AM, Brendan Eich <[email protected]> wrote:
> Seems like we are yet again talking ourselves out of unique symbols -- or
> symbols in general?
>
> I still see big usability problems with UUIDs, even if used to name
> non-enumerable properties. Tools help but the core language provides no
> sugar, salt, or paprika. Just a very sour/bitter hex-string...
>
> /be
>
>
> Kevin Smith wrote:
>
>>
>>
>> To avoid accidental collision on the interned symbols, you must
>> avoid accidental collision on the strings used as keys in this
>> registration table. This demands exactly as much collision
>> resistant of string choices as using the strings directly. And
>> therefore also demands strings which are just as ugly.
>>
>>
>> I agree. A unique string to symbol registry would be a useless
>> indirection, as there is no information or ability stored in the symbol
>> that is not already inherent in the string used to fetch the symbol.
>>
>> The solution to your version+realm problem of this post is trivial with
>> string names. Just use a well-known unique string (uuid or otherwise).
>>
>> { Kevin }
>>
>> ______________________________**_________________
> 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
