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

Tom Van Cutsem at
Thu Dec 22 04:12:48 PST 2011

2011/12/22 Andreas Rossberg <rossberg at>

> On 21 December 2011 20:42, Tom Van Cutsem < at> wrote:
> > The cleanest approach so far seems to be to either return a per-call
> unique
> > sentinel value or a tuple (true, realReturnValue) or false. Both
> introduce
> > extra per-call allocation, and add more complexity to an already complex
> > API.
> Frankly, I don't see the necessity to have a fresh sentinel value per
> call. There is no serious issue with taking one designated,
> API-specific value out of the domain of proper values for that
> operation (especially considering that you just suggested using
> undefined, which certainly is more intrusive ;) ).


> > I would not consider either to be a big improvement over proxies not
> > being able to forward private names unknown to them.
> > By the way, it occurred to me that from a security perspective, it is odd
> > that a proxy p can decide on the outcome of p[n] even if it does not know
> > about n: a client of p might assume that p[n] is a "reliable" value,
> since
> > it could only have been stored there by another party with knowledge of
> n,
> > and "private names don't leak through proxies". Yet the proxy might fool
> its
> > client into thinking it does know of n, since it can provide a
> non-undefined
> > value for p[n]. That's an argument if favor of not allowing proxies to
> > intercept private names ever, not even with .public conversion.
> I strongly believe that any ad-hoc behavioural distinction that we
> need to introduce between plain and private property names indicates a
> problem with the semantics of either private names or proxies (or JS
> objects in general, which is the scariest case). We should try very
> hard to avoid them.
> Regarding your specific argument above, I'd argue that it is not
> actually odd. Any attempt to set private properties on objects you do
> not "own" is highly questionable to start with. Don't expect it to
> work.

Hmm, while I share your point of view, I don't think this fully aligns with
the envisioned use of private names. One use case of private names is to
enable more modular monkey-patching. For this use case, the whole point is
to set private names on objects you don't own. However, the private names
strawman page states that in those cases the privacy of the name doesn't
matter as much as its uniqueness. So your point applies to the subset of
use cases of private names where privacy is important.

And in all other cases you should usually be able to set up
> their behaviour properly. That is, I currently don't see a valid use
> case for accessing a private property on a proxy unless you created
> the proxy yourself. (Though I just realised that Proxy.attach creates
> a huge issue there...)
> I can also turn your argument around. Wouldn't it be much odder if I,
> as a proxy implementer, cannot keep others from setting unwanted
> properties on my own object, no matter what the name is?

Weak maps can achieve a similar relationship without the proxy intervening,
but I agree that for private names it's more odd, since a private name is
logically an own property of the object.

For the modular monkey-patching use-case, it seems reasonable to allow
proxies to intercept such private names.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list