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

Andreas Rossberg rossberg at google.com
Wed Dec 21 02:25:15 PST 2011


On 20 December 2011 21:06, David Bruant <bruant.d at gmail.com> wrote:
> Le 20/12/2011 14:45, Andreas Rossberg a écrit :
>> On 17 December 2011 00:24, Sam Tobin-Hochstadt <samth at ccs.neu.edu> wrote:
>>> You might want to implement an object with a private field and a
>>> public method like this:
>>>
>>> let o = (function () { let n = new Name(); return { [n]: 0; get:
>>> function() { return this[n]; }}})();
>>>
>>> But, if we don't censor private names in proxies, this abstraction leaks!
>>>
>>> Consider:
>>>
>>> let p = new Proxy(...);
>>> o.get.call(p);
>>>
>>> Now the name is leaked to the proxy.  And there's no way you can fix
>>> this, without resorting to some other method of hiding things like
>>> closures.
>> Hm, isn't this example rather demonstrating that the ability to do
>> self stealing -- i.e., the lack of lexical `this' -- is violating
>> basic abstraction principles (as we all know)?
> This particular example used 'this', but similar examples may not.
> -----
> let marker = (function(){
>    let n = new Name();
>    let counter = 0;
>
>    return {
>        mark: function(o){
>            o[n] = counter++;
>        }
>        readMark: function(o){
>            return o[n];
>        }
>    };
> })();
>
> marker.mark(maliciousProxy);
> -----
>
> ...and the name just leaked allowing a malicious proxy to mess with the
> marking.

Sure, but o here is just a random argument, and you can never make any
assumptions about what gets passed as an argument (unless you have
some kind of nominal type or branding mechanism).

Whereas `this' refers to the object on which the method itself sits,
so intuitively its "own" object. Not so in JS, I know, but it's the
very basis of standard OO-style abstraction/encapsulation. That is,
without binding `this' (or avoiding it altogether) there is no
reliable way to build an object-oriented abstraction and ensure your
own invariants. Potential leakage of private names is just a symptom.


> Indeed. What do you think of the different alternative proposals
> (especially regarding the "ad-hoc complications" you point out)?

I agree with your analysis that passing the public view of a private
name to traps is not a true reification. However, I'm not sure I
prefer the alternative you propose. Putting a random flag on names to
control the behaviour of a completely different language feature seems
awkward, and introduces undesirable conceptual coupling.

In essence, you are introducing two separate types of private names,
but the distinction only is observable in situations that the
implementer should not need to think about in the first place. What
would be the guideline for picking the right one? When would I ever
want to pick the weaker variant?

/Andreas


More information about the es-discuss mailing list