On Thu, Dec 16, 2010 at 4:27 PM, Brendan Eich <bren...@mozilla.com> wrote:
> On Dec 16, 2010, at 3:57 PM, Mark S. Miller wrote: > > On Thu, Dec 16, 2010 at 3:51 PM, David Herman <dher...@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_representationyou > write: > > "This representation parallels the implementation techniques and resulting > performance benefits expected for > names<http://wiki.ecmascript.org/doku.php?id=strawman: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. > 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 > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
