New private names proposal
Mark S. Miller
erights at google.com
Thu Dec 16 16:44:00 PST 2010
On Thu, Dec 16, 2010 at 4:27 PM, Brendan Eich <brendan at 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 <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
> 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.
> 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
> (note: not http://wiki.ecmascript.org/doku.php?id=strawman:names) as
> "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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss