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 <[email protected]> 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 <[email protected]> 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 <[email protected] >> > wrote: >> >>> >>> On Sep 26, 2013, at 3:13 PM, Rick Waldron wrote: >>> >>> >>> >>> >>> On Thu, Sep 26, 2013 at 6:02 PM, Erik Arvidsson < >>> [email protected]> 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@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@events" also makes >>> such accidentally unlikely. >>> >>> Allen >>> >>> _______________________________________________ >>> es-discuss mailing list >>> [email protected] >>> https://mail.mozilla.org/listinfo/es-discuss >>> >>> >> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> >> > > > -- > Cheers, > --MarkM >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
