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

Andreas Rossberg rossberg at
Thu Dec 22 01:47:39 PST 2011

On 21 December 2011 20:42, Tom Van Cutsem < at> wrote:
> 2011/12/21 Herby Vojčík <herby at>
>> From: Andreas Rossberg
>> Unfortunately, I don't have a good suggestion for a convenient
>> interface, besides introducing a sentinel value that traps can return
>> (I am still puzzled how people can survive in dignity without variants
>> and tuples... :) ).
>> ===
>> I was proposing some solutionto exactly this in "Forward proxies with
>> private names" thread. Not acceptable (especially the call, if exception is
>> too hard to swallow)?
> Two reasons against:
> 1) Probably introduces a high overhead, since it implies every trap
> invocation needs to be wrapped in a try-block to catch the exception. Under
> no circumstances should such an exception unwind the stack any further, to
> avoid confusing other trap invocations on the stack.
> 2) Misuse of exceptions: asking a proxy to "please forward" is not an
> exceptional situation. I was taught it is bad API design to abuse exceptions
> for non-exceptional situations.

I agree that exceptions are the wrong approach. Same goes for
functions, especially since nothing prevents you from storing them and
calling them out of context, which must be discovered and handled.

> 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. 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?


More information about the es-discuss mailing list