Private names use cases

Mark S. Miller erights at
Tue Dec 21 09:03:04 PST 2010

On Mon, Dec 20, 2010 at 9:21 AM, Allen Wirfs-Brock <allen at>wrote:

> I've seen mentions in the recent thread that the goal of the "Private
> Names" proposal was to support "private fields" for objects.  While that may
> be a goal of some participants in the discussion, it is not what I would
> state as the goal.
> I have two specific use cases in mind for "private names":
> 1) Allow JavaScript programmers, who choose to do so, to manage the direct
> accessibly of object *properties*.  This may mean limiting access to
> methods of a particular instance, or to methods of the same "class", or to
> various friends or cohorts, etc.
> 2) Allow third-party *property* extensions to built-in objects or
> third-party frameworks that are guaranteed to not have naming conflicts
>  with unrelated extensions to the same objects.
> Of these two use cases, the second may be the more important.

I'm glad you agree. By incremental fiddling, such as repairing the
encapsulation leaks of private names, perhaps we could brings these two
proposals closer together to try to find common ground. However, this second
use case would still be a real difference. <>
uses your example of this use case. In light of your message, I just added a
note on the crucial difference:

For defensive programming, best practice in many environments will be to
freeze the primordials early, as the dual of the existing best practice that
one should not mutate the primordials. Evaluating the dynamic behaviour of
Python applications <> (See
also provides evidence that
this will be compatible with much existing content. We should expect these
best practices to grow during the time when people feel they can target ES5
but not yet ES6.

Consider if Object.prototype or Array.prototype were already frozen, as they
should be, before the code above executes. Using soft fields, this extension
works. Using private names, it is rejected.

> Note that I emphasized "properties" rather than a new concept such as
> "private fields".  I believe we should be trying to build upon the
> conceptual foundation of the existing JavaScript object model whenever
> possible. We should strive to avoid introducing new concepts such as
> non-property fields into the object model.  (see
>  for further thoughts on this
> topic.)

I find this latter point and your elaboration on that web page bizarre. It
is the private names proposal that would change the object model, even if
you consider these changes minor. The soft fields proposal does not change
the object model *at all*. It has the semantics of a side table.

It seems both of your key points in this message support soft fields over
private names.

> Allen
> _______________________________________________
> es-discuss mailing list
> es-discuss at

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list