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() ==
"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

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?