Comments on Sept Meeting Notes

Yehuda Katz wycats at gmail.com
Thu Sep 26 16:13:31 PDT 2013


I don't understand why any registry is needed. Imagine a module
"ember/symbols" implemented like this, assuming some sharedSpace that
modules have access to cross-realms.

```
var guid = "<generated literal>", symbol;
if (sharedSpace[guid]) {
  symbol = sharedSpace[guid];
} else {
  symbol = sharedSpace[guid] = new Symbol("friendly name");
}

export meta = symbol;
```

And then in any realm:

```
import { id } from "ember/symbols";

// use `id` symbol
```

So you still coordinate over Strings, but you don't need a VM-level
registry, just a user-land one.

Yehuda Katz
(ph) 718.877.1325


On Thu, Sep 26, 2013 at 4:07 PM, Mark S. Miller <erights at google.com> wrote:

> I think we swept the collision problem under the registry rug. Let's start
> by discussing registry designs assuming we do have Symbols. Let's see if we
> can design a registry that allows cross-realm duck typing without
> re-introducing the same possibility of accidental collision that we'd have
> without Symbols. Note: For this question, malicious collision is not an
> issue.
>
>
> On Thu, Sep 26, 2013 at 4:02 PM, Rick Waldron <waldron.rick at gmail.com>wrote:
>
>>
>>
>>
>> On Thu, Sep 26, 2013 at 6:51 PM, Domenic Denicola <
>> domenic at domenicdenicola.com> wrote:
>>
>>>
>>>
>>> > On Sep 26, 2013, at 18:49, "Yehuda Katz" <wycats at gmail.com> wrote:
>>> >
>>> > Private state doesn't satisfy these requirements because they trap on
>>> the wrong side of the proxy.
>>>
>>> Agreed, in many cases I don't want private state; I *want* something
>>> that can be copied by Object.mixin, for example. For private state, weak
>>> maps are fine, and used today already.
>>>
>>
>>
>> Agreed with Yehuda and both of Domenic's points. I don't need/want Symbol
>> for private anything—I want it for cases that don't deserve a WeakMap,
>> should be reflected and can be "seen" by Object.getOwnPropertySymbols(),
>> but want to avoid the possibility of collision.
>>
>> Rick
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
>
> --
>     Cheers,
>     --MarkM
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130926/d7feb9a0/attachment.html>


More information about the es-discuss mailing list