On 18 May 2011 18:27, Allen Wirfs-Brock <al...@wirfs-brock.com> wrote: > In general, it is a good idea to avoid new global names that aren't going to > be in modules. In particular, there is no particular reason these factory > methods shouldn't be visible via the Harmony "ES5" global object. In that > case hanging them off an existing constructor carries less risk of > collisions (but not no risk) with user defined name. "Name" seems like it > might be a particularly risky global to grab. Luke suggested hanging them > off Object and in my working draft I suggest String. Either is probably > safer than adding new globals.
Hm, making name creation a method of String seems equally odd -- unless you also plan to have typeof String.createPrivateName() == "string". Of course, I see the concern with the global object (although 'Name' was only a strawman suggestion). I assume that we need a future-proof solution for adding new built-in objects anyway, most likely based on modules. And that accessing built-in objects through the global object will be deprecated in Harmony code. So, since private names will be Harmony-specific, their constructor doesn't have to be visible through the "old" ES5 global object. Wouldn't introducing a new built-in constructor in some module scope actually have less risk (none?) of producing name clashes than messing with an existing object? /Andreas _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
