Le 08/11/2011 11:54, Tom Van Cutsem a écrit : > > > About [[SetP]]: > * It seems to me that we've traded a duplicated [[GetProperty]] > call for > a duplicated [[GetOwnProperty]] (Step 1 and 5.a) call on the receiver. > This could be avoided by storing the property descriptor at the > beginning (when O.[[setP]](Receiver, P, V) is called and O === > receiver). Step 5.a could be remove by the change. > > > The double [[GetOwnProperty]] invocation on the initial receiver > should not be observable: if the initial Receiver of [[SetP]] is a > proxy, the proxy's [[SetP]] algorithm (which triggers the "set" trap) > executes instead of this algorithm. Very true. And even if there is no trap, the default action is to trigger [[Set]] on the target, so no duplicated call.
> (...) > > Long story short: the "O" variable in the [[SetP]] algorithm always > denotes a normal non-proxy object. In general, the "Receiver" variable > can be any object. > > > * If step 5.a is removed, I think that step 5.b.i is useless, > because we > would have returned from the set when O was the receiver (by step > 2.a of > [[setP]]) > * If step 5.a is removed, then step 5.c is useless, because if the > desc > had a [[set]], then we would have already returned from one of the > substep of step 3 when O was the receiver > > Why not redefining [[Get]] as what you have defined as [[GetP]] and > equivalent for [[Set]] and [[SetP]]? > Current 8.12.3 [[Get]] (P) would become [[Get]] (Receiver, P). It > would > be called with O as initial value for Receiver pretty much > everywhere in > the spec except within [[Get]] recursive calls. > Equivalent for [[Set]]. > It would prevent the replacement of 2 Object.* methods by 2 others. > > > The reason I introduced separate [[GetP]] and [[SetP]] methods is > simply so that the "public API" of Objects remained intact. Your > suggestion is reasonable: trade proliferation of built-in methods for > a small public API change in the spec. I guess this is just a matter > of find/replacing all the calls to [[Get]]/[[Put]]. Exactly, that's what I had in mind. > Might even be an opportunity to get rid of "put" and use "set" > consistently throughout the spec. I cannot agree more with this idea. Especially with proxies having a "set" trap and accessor properties having "setters", [[Put]] sounds wrong even though that has been the name in ES5, ES3 (and even before?) > > With the refactoring, on the direct proxy strawman, I don't think we > need the "proxy" argument for the get and set traps anymore. It > was here > as the receiver, but since we have the receiver itself, the get > and set > trap can just have the receiver and the target as argument. > > > Good point. I'd wager that in most use cases, knowing that |receiver| > is either your own proxy or a descendant of that proxy is > sufficient. I can't currently think of a use case where the get/set > trap would really want to be able to access the proxy itself, not just > the proxy or a descendant.That doesn't mean that use cases for it > don't exist, however. Oh true, I thought that proxy and the receiver were the same objects but if the proxy is on the prototype, it is not the case. > I guess if access to the proxy is really needed, it's easy enough to > accomplish: > > var p = Proxy.for(target, handler); > handler.proxy = p; Indeed. David
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
