Alternative proposal to privateName.public

David Bruant bruant.d at gmail.com
Tue Dec 20 09:57:51 PST 2011


Le 17/12/2011 14:24, David Bruant a écrit :
> (...)
>
> # Proposal
>
> What about a 'trapped' boolean in the private name constructor?
>
> It would work this way:
>
> `````JavaScript
> var n = new Name(false); // don't trap when used is a proxy
> var p = new Proxy({}, maliciousHandler);
>
> p[n] = 21; // the set trap is NOT called!
> var v = p[n]; // the get trap is NOT called and v === 21
> `````
>
> Basically, when the private name is created with the 'trapped' boolean
> to false, the proxy becomes oblivious to being called with these private
> names.
There has been some other proposals suggesting ways to bypass the proxy
to work directly on the target. Since I have been brief, my proposal
could be interepreted as such and it was not my intention. So here are
additional code snippets to further explain my proposal.
-----
var n = new Name(false); // untrapped name
var t = {};

var p = new Proxy(t, maliciousHandler);

p[n] = 21; // the malicious set trap is NOT called!
var v = p[n]; // the malicious get trap is NOT called and v === 21

Object.getOwnPropertyDescriptor(t, n); // undefined
-----

In this proposal, in the case of untrapped names, only the proxy
identity is used internally. No trap is called and the target remains
untouched.
There is neither implicit nor explicit forwarding to the target. If the
code in possession of both a reference to the private name and a
suspicious object does not want the suspicious object to have to do
anything with the name, it can define the private name as untrapped and
the proxy will be oblivious to the private name.

This choice is made in order to make the private name owners responsible
for what they do with the private name, choose who they want the name to
be shared with.

David


More information about the es-discuss mailing list