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 <brendan at mozilla.com> 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
> es-discuss at mozilla.org
> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130731/9a8ff887/attachment.html>

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

```js
// example
var sym = new Symbol;
var o = {};
o[sym] = 123;
console.log(o[sym]);
```