July 26, 2012 TC39 Meeting Notes
Tom Van Cutsem
tomvc.be at gmail.com
Wed Aug 1 10:19:44 PDT 2012
2012/8/1 David Bruant <bruant.d at gmail.com>
> Le 01/08/2012 09:07, Tom Van Cutsem a écrit :
> 2012/7/31 David Bruant <bruant.d at gmail.com>
> Maybe the details I propose are not perfect, but I think there is a
>> game-changer in the idea of a handler being able to share with the JS
>> implementation which secrets it knows.
> I don't like it. It introduces mutable state into the proxy-handler
> protocol, which is currently fully functional.
> I partially disagree. One of the reason I chose Set/WeakSet in my
> demonstration is that the after-trap code would only call Set.prototype.has
> (the built-in one, not the dynamic one for security reasons), leaving the
> API somewhat fully functional.
> knownPrivateNames could be made a function with signature Name -> Boolean
> (I would prefer too), but if the after-trap code calls it with the private
> name as argument, it leaks the private name, so that cannot work... or
> maybe there is a way.
I should have phrased that differently: currently, the handler can be a
stateless/immutable object, and as a result, you can have a single handler
handle many proxies. Associating a mutable (Weak)Set by default with each
handler destroys that simple model.
> The proxy makes a minimum of dependencies on the handler's behavior, and
> only interacts with it via property access of trap names (crucial for
> double lifting).
> The "isPrivateNameKnown" property could also be only interacted with
> through property access of trap names.
> Also, since a handler's properties may be mutable, you have to account for
> the fact that a trap can be updated, thus there is the potential issue of
> the handler's internal state growing out of date.
> As you're saying below, handlers will often need weakmaps to tack
> additional state, so guarding internal state consistency is already a
> problem in the current setting.
To me, the fact that this special "isPrivateNameKnown" property must be a
built-in WeakMap, or some such, to guarantee that the private name doesn't
leak, signals that we are just shifting the problem. Now we have yet
another kind of interaction point with the handler where we must make sure
the private name does not leak.
Also, the gains are not at all clear to me. Are there big savings to be
had? In your proposed design, the "after-trap" still needs to verify
whether the handler knows the private name, by doing a lookup in some
associative data structure. But the trap will most likely already need to
do such a lookup itself (the handler will itself likely need to check
whether its knows the name). In that case, the handler just returns the
private name as a result and the proxy readily verifies, no extra lookup
I can also imagine that some handlers will have a specific private name in
scope and can just return it as-is, without ever needing an associative
data structure to hold the private name. At that point, your proposed
mechanism adds more overhead by requiring that handler to store the value
in the map/set, and by making the proxy do an additional lookup.
> Part of the reason why we decided to fork the regular traps into
> additional *Name traps is that we wanted to keep the "type signature" of
> the existing traps unmodified. Your proposal 1) would change the type of
> the "name" argument from String to (String | Name). So a programmer might
> still need to do a case-analysis in the body of each trap.
> Why would a programmer do that? Will the built-ins ([[DefineOwnProperty]],
> [[Get]], etc.) do case-analysis to distinguish string and names? If they
> don't, I don't really see why the programmer would. In most cases, one will
> just forward to Reflect.trap(stringOrName, ...).
> It's actually very likely that in specifying the default *Name traps, they
> will have the exact same code than their string counterpart, the only
> difference will be that the passed values have different types.
> The argument I'm trying to make is that essential internal methods (as per
> terminology in ) will be polymorphic and there is no reason why traps
> shouldn't be.
Ok, I buy the analogy to the internal methods. It simplifies things if you
can think of proxy traps as corresponding 1-to-1 with the [[internal]]
methods defined on Objects. If the signature of those methods changes,
maybe proxy traps should follow suit. I'd like to hear Allen's opinion on
It's true that we could make the Reflect.* methods name-aware, at which
point methods that operate on property names such as Reflect.defineProperty
are no longer just aliases for the ES5 built-ins like Object.defineProperty
(for which I doubt that the method signature will change).
I share your concern that proxy handlers will probably need to duplicate
logic in the new *Name traps.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss