2011/5/18 Andreas Rossberg <rossberg at google.com>:
> Separating out the functionality of abstract names certainly is a good idea.
>
> But is there any reason to make it a method of Object? In essence,
> private names form a new primitive type, so there should be a separate
> global object or module for them. Assuming for a minute it was called
> Name (which clearly is a suboptimal choice), then you'd rather invoke
> Name.create(), or perhaps simply Name() (by analogy with calling
> String(v) to create primitive strings, although I'm not sure I like
> the notational abuse behind it).

It would be nice to do Name("foo") or PrivateName("foo") so that the
debugger has some name to use when displaying objects with private
fields.  Alternatively, I suppose the debugger could guess the name
like it does currently for Foo.prototype.myFunc = function() .... This
has the disadvantage that a library that uses unique strings to
simulate some of the features of private names on older browsers would
not be able to give the unique names a meaningful prefix.

-- 
Erik Corry

It would be nice to do `Name("foo")` or `PrivateName("foo")` so that the
debugger has some name to use when displaying objects with private
fields.  Alternatively, I suppose the debugger could guess the name
like it does currently for `Foo.prototype.myFunc = function() ...`. This
has the disadvantage that a library that uses unique strings to
simulate some of the features of private names on older browsers would
not be able to give the unique names a meaningful prefix.