New private names proposal

[Brendan Eich]

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 mozilla.com> 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 <http://wiki.ecmascript.org/doku.php?id=strawman:inherited_explicit_soft_fields#a_transposed_representation>. 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 http://wiki.ecmascript.org/doku.php?id=strawman:inherited_explicit_soft_fields#a_transposed_representation 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

http://wiki.ecmascript.org/doku.php?id=strawman:private_names

(note: not http://wiki.ecmascript.org/doku.php?id=strawman:names) as follows:

[http://wiki.ecmascript.org/doku.php?id=strawman:private_names#proxies]

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

/be
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20101216/5996751f/attachment.html>