On Fri, Sep 27, 2013 at 11:07 PM, Brendan Eich <[email protected]> wrote:
> Brendan Eich <mailto:[email protected]> >> September 11, 2013 9:17 AM >> FYI and dirty >> > > LOL, something else was spellchecked there. __nSM__ is truly dirty ;-). > > > if it doesn't matter: ES6 adds an invoke trap to proxies. Cc'ing Allen. >> > > We are debating still, but invoke would be a derived (optional) trap to > avoid method allocation from get, at most. HTH, > > /be > Maybe how __NSM__ is used can provide meaningful feedback for that debate. Briefly, the invoke trap on proxies is called into question for two reasons: 1. there are some cases the .invoke trap doesn't handle, and that might complicate proxy usage too much Specifically, these two patterns aren't handled by .invoke, with the first one requiring coordination with the get trap, and the second one not being affected by the invoke trap at all: `if (obj.method) obj.method()` `var method = obj.method; // more code if (method) method.call(obj);` 2. the usecases aren't entirely clear, so it's also not clear whether they're enough to merit inclusion of the trap ISTM that __nSM__ is in the same boat as the invoke trap regarding both of these points. My question is, in which ways is __nSM__ used, and are there usages that clearly profit from being able to trap method calls independently from property lookups? Maybe even to the point of becoming infeasible if that were to go away. till _______________________________________________ dev-tech-js-engine-internals mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
