New private names proposal

Mark S. Miller erights at
Thu Dec 16 16:44:00 PST 2010

On Thu, Dec 16, 2010 at 4:27 PM, Brendan Eich <brendan at> wrote:

> 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
> 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.

I'll address this last point first, since this seems to be the core issue.
The question I am raising is: given soft fields, why do we need private
names? I translated your examples to show why I see no need for the latter.
If we don't need them, we shouldn't add them.

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

> /be

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

More information about the es-discuss mailing list