rossberg at google.com
Thu May 19 03:04:45 PDT 2011
On 18 May 2011 18:27, Allen Wirfs-Brock <allen at 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() ==
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?
More information about the es-discuss