Le 02/08/2012 15:26, Sam Tobin-Hochstadt a écrit :
On Thu, Aug 2, 2012 at 2:00 PM, Tom Van Cutsem <[email protected]> wrote:
[reordering a little]
Your observation that the value to be set leaks to a
setName/definePropertyByName trap is spot-on. It's indeed the dual of
protecting the return value in the getName trap. I can imagine a solution
that involves the trap returning a callback that will receive the value
after it has proven that it knows the private name, but this is really
becoming tortuous.
Your proposed alternative is something to consider, although I'm still
uncomfortable with the WeakMap.prototype.has.bind mechanic. We should also
reconsider the simplest alternative of just not trapping private names on
proxies.
I agree that the current design is a leak, and that the callback
approach is quite heavyweight. However, I don't think we should give
up on trapping altogether.
Instead, we could consider some simpler options. Basically, the proxy
creator should specify the private names that are to be trapped, and
all others are simply forwarded to the target object.
I still think the proxy should be able to prevent such a direct access
for unknown private names by throwing.
Here is a situation where it's necessary:
You give access to Alice and Bob (both untrusted) to an object o via a
proxy using a membrane. You wish to allow both to communicate only
through their access to o (and what results from that communication).
When you want to cut their ability to communicate, you want to disable
access to anything inside the membrane.
If unknown private names to the membrane aren't trapped, then Alice and
Bob can still communicate, defeating the goal.
How do they share such a private name if private names are also in the
membrane?may you asj.
The answer is that private names may not be in the membrane. Tom
mentioned it that he wanted to make private names unwrappable values and
I think that makes sense:
var n = new PrivateName();
var p = new Proxy(n);
Is p a private name too? I don't think so, but that's an interesting
discussion to have.
I can see a few ways of doing this.
1. Add an optional array argument to Proxy.for, which contains private
names to trap. If it's omitted, no names are trapped. This also
means that for anyone who doesn't explicitly ask for it, the type
signatures of the proxy traps remains simple.
2. Same as 1, but the array is checked on every trapped operation, so
that it can be updated.
3. Similar to 2, but there's an operation to add new names to trap,
instead of a live array.
I love this idea.
I think an array would be a mistake and a (Weak)Set would be more
appropriate, because traversing an array has to be in linear time which
has no reason to be a constraint in an ES6 compliant platform with
WeakSets. YMMV. Maybe any collection could work.
I'm inclined to go for 3 and the proxy creator has the possibility to
add elements afterwards directly to the shared set via set.add. No need
for a specific operation to add new names.
1 is clearly the simplest, but doesn't support membranes properly, I
think. 2/3 have the drawback that handlers now have state.
The handler doesn't have state with your proposal, only the proxy does
acquire a new piece of internal state. But that's fine I think. The
target is a form of state that isn't problematic, I don't see why this
would be.
David
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
