On Dec 16, 2010, at 3:57 PM, Mark S. Miller wrote:
> On Thu, Dec 16, 2010 at 3:51 PM, David Herman <[email protected]> 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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
