July 26, 2012 TC39 Meeting Notes
bruant.d at gmail.com
Thu Aug 2 12:57:49 PDT 2012
Le 02/08/2012 15:26, Sam Tobin-Hochstadt a écrit :
> On Thu, Aug 2, 2012 at 2:00 PM, Tom Van Cutsem <tomvc.be at gmail.com> 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
> 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
More information about the es-discuss