If that's the case, we haven't thought the registry through well enough.
You should get the cross-realm symbol through imports.

Yehuda Katz
(ph) 718.877.1325


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

> Once you add the registry, all these accidental collisions problems come
> back. If you don't add a registry, you lose the ability to duck type across
> realms.
>
>
> On Thu, Sep 26, 2013 at 3:45 PM, Yehuda Katz <wycats at gmail.com> wrote:
>
>> I prefer Symbol names for the reasons I said at the last meeting:
>>
>> * Non-enumerability by default (the other solutions presented in this
>> thread are finicky, harder to explain, and potentially error-prone).
>> * Guaranteed duck-testability: if an object tests positive for
>> iterability, it much be intentional. Once we start using @ as a symbolic
>> prefix, userland libraries will likely start to use it too, making
>> duck-tests of future names inconclusive. I'm also not convinced that @foo
>> isn't already used for this purpose in the wild, but even if that's true,
>> it only solves the issue for one generation.
>> * Intention-preserving: You get to use a short, English name as the
>> method name with just a bit of syntactic chrome, and you don't have to
>> worry about the tradeoff between collisions and leaking indecipherable
>> names to debugging.
>>
>> Yehuda Katz
>> (ph) 718.877.1325
>>
>>
>> On Thu, Sep 26, 2013 at 3:33 PM, Allen Wirfs-Brock <allen at wirfs-brock.com
>> > wrote:
>>
>>>
>>> On Sep 26, 2013, at 3:13 PM, Rick Waldron wrote:
>>>
>>>
>>>
>>>
>>> On Thu, Sep 26, 2013 at 6:02 PM, Erik Arvidsson <
>>> erik.arvidsson at gmail.com> wrote:
>>>
>>>> No surprise here, but I also support using "@" methods.
>>>
>>>
>>> I don't. Please see my response to Kevin Smith:
>>> https://mail.mozilla.org/pipermail/es-discuss/2013-September/033720.html
>>>
>>>
>>> I'm also in
>>>> favor of making methods non enumerable by default. This makes them
>>>> more consistent with what we have in ES today.
>>>
>>>
>>> That might be the case for methods defined on prototypes of built-in
>>> objects, but it's absolutely not the case for user land code. Please see
>>> the examples in my previous response to Allen:
>>> https://mail.mozilla.org/pipermail/es-discuss/2013-September/033725.html
>>>
>>>
>>> so name your events property "@RickWaldron at events".
>>>
>>> If somebody subclasses Emitter and know that property name, then they
>>> must be doing something intentional.
>>>
>>> Unique Symbols don't guarantee that sort of integrity. All you've
>>> accomplish by using them as in your example is to minimize that chance that
>>> somebody else doesn't accidentally use the same property name for some
>>> other purpose.  Naming your property "@RickWaldron at events" also makes
>>> such accidentally unlikely.
>>>
>>> Allen
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
>
> --
>     Cheers,
>     --MarkM
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130926/623da703/attachment.html>

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

> Once you add the registry, all these accidental collisions problems come
> back. If you don't add a registry, you lose the ability to duck type across
> realms.

If that's the case, we haven't thought the registry through well enough.
You should get the cross-realm symbol through imports.