Are Private name and Weak Map the same feature? and the Assoc API

David Herman dherman at mozilla.com
Sat Dec 17 13:37:16 PST 2011


On Dec 17, 2011, at 4:04 AM, David Bruant wrote:

> I propose to accept that "o[n]" may disclose 'n' if 'o' is a proxy.

This is just a non-starter. Then you can't use private names as private names.

> (One good news is that mostly static analysis
> can assist us in finding where we may disclose 'n' in this scenario).

When you say "static analysis can solve this" you're saying "some hypothetical approximation to an undecidable problem will find out all the places where the unstated and unwritten intentions of the programmer were violated. Also, despite the fact that it's mathematically impossible for such a tool to have both no false positives and no false negatives, it will still be both safe and useful." I'll believe it when I see it?

Besides, we shouldn't knowingly add features that will invite bugs that can only be found with (as yet unspecified and non-existent) additional development tools.

>> But, if we don't censor private names in proxies, this abstraction leaks!
> I agree, but this is not inherent to private names, it is inherent to
> how you wrote your example. In a world where "o[n]" may disclose 'n',
> exposing a method with the instruction "this[n]" is a dangerous thing to
> write, indeed.
> It is as dangerous as writing "this.foo(n)". No more no less.

One of the important use cases of private names is the ability to create private data that collaborators can share. More specifically, two of the most common collaborators in JS are constructor functions and prototype methods. If you make it so that this[n] is no longer safe, then constructors and prototype methods can no longer use private names to collaborate with private properties.

>> And there's no way you can fix
>> this, without resorting to some other method of hiding things like
>> closures.
> I disagree, there is.
> In the case where you want the proxy ("worst case", here "proxy" means
> "untrusted third party") to have access to the private name, you need
> the proxy to have access to a public->private map.

You seem to be treating ES6 as being The Ultimate Proxy Language (with some additional side features). Proxies are not the common use case we are optimizing for, nor should they be.

The common case we are optimizing for has nothing to do with proxies. It's simple stuff like:

    let n = Name();
    function Stuff() {
        this[n] = /* some internal stuff */;
    }
    Stuff.prototype = {
        doStuff: function() {
            ... this[n] ...
        }
    };

> If each time I create an abstraction using proxies, I need a
> public->private map, it is likely that I (and it's obviously not about
> "me", but anyone writing proxies) won't use private names with proxies.
> I may just use WeakMaps.

Great -- do that! If proxy writers have to work harder to deal with the public/private map, so be it! I would much rather tax proxy writers than tax everyone else. As cool as proxies are, they are not intended to be nearly as common as the usual simple functions + prototypes abstractions of JS.

Dave



More information about the es-discuss mailing list