New private names proposal

Brendan Eich brendan at
Thu Dec 16 16:27:50 PST 2010

On Dec 16, 2010, at 3:57 PM, Mark S. Miller wrote:

> On Thu, Dec 16, 2010 at 3:51 PM, David Herman <dherman at> wrote:
> Without new syntax, isn't soft fields just a library on top of weak maps?
> Semantically, yes. However, as a library, they cannot benefit from the extraordinary efforts of all JavaScript engines to optimize inherited property lookup. Nor from the GC benefits that follow from the transposed representation explained at <>. OTOH, if soft fields are built in and implemented in this transposed manner, both benefits easily follow.

Have you talked to any JS engine implementors about any of this? If so, more details would be great.

Private name property name lookup is not transposed into a get along the prototype chain followed by a method call, and calling a method is inherently costlier than getting a property, in all the JS engines I've studied. Private names use exactly the same optimized lookup paths today's engines sport, just with a different type of identifier.

In you write:

"This representation parallels the implementation techniques and resulting performance benefits expected for names but without the semantic problems (leaking via proxy traps and inability to associate soft state with frozen objects)."

but the first point in the parenthetical aside was addressed by Allen's writeup at

(note: not as follows:


"The Proxy object could be replaced with an alternative implementation that added an additional handler layer that would wrapper all private name values passed through its traps. The wrappers would be opaque encapsulations of each private name value and provide a method that could be used to test whether the encapsulated private name was === to an argument value. This would permit handlers to process known private name values but would prevent exposing arbitrary private name values to the handlers.
If there is sufficient concern about proxies exposing private name values in this manner, such wrapping of private names could be built into the primitive trap invocation mechanism." 

Please update your page accordingly.

The other parenthetical point, the inability to associate soft state with frozen objects, is a feature of private names, not a bug. If it's an important use case then we can certainly use soft fields (given weak maps) to solve it.

This does *not* mean soft fields and private names are mutually exclusive and locked in some "there can be only one!" Highlander contest.

Really, it's starting to feel like "Survivor" or "American Idol" around here. The apples to oranges death-matching has to stop.

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

More information about the es-discuss mailing list