July 26, 2012 TC39 Meeting Notes
samth at ccs.neu.edu
Thu Aug 2 12:26:25 PDT 2012
On Thu, Aug 2, 2012 at 2:00 PM, Tom Van Cutsem <tomvc.be at gmail.com> wrote:
[reordering a little]
> Sam, if I'm not mistaken, Racket has both names and proxies (aka
> impersonators), can you shed some light on how those features interact? Do
> chaperones/impersonators need to treat names specially?
In Racket, the entire class system, including private names, is built
as a library, and doesn't provide any proxying mechanism itself, and
the lower-level proxy system can't intercept message sends, since
they're implemented abstractly from the perspective of the client. So
there isn't a direct analogy here.
However, in Racket you can specify contracts on classes, including
contracts on methods which are named by private names. This requires
specifying the intercession on a per-method basis, and so to intercede
on a private-named method, you have to have the private name to start
> 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 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.
1 is clearly the simplest, but doesn't support membranes properly, I
think. 2/3 have the drawback that handlers now have state.
samth at ccs.neu.edu
More information about the es-discuss