On Sep 20, 2013, at 5:31 PM, Brendan Eich wrote: > Allen Wirfs-Brock wrote: >> The main reason I'm still supportive of [[Invoke]] (possibly with the option >> of passing a function instead of a property key) is because it allows (and >> that I think you pointed out) a proxy to implements some or all of its >> methods directly in its 'invoke" trap rather than as discrete functions. > > Only if the client code doesn't extract a method as a funarg. There's no way > around get and invoke having to be consistent. > > JS has first class functions, methods are not second class, so invoke cannot > relieve a proxy from reifying methods from get. > > Given this, having the legacy internal calls continue to use get+call seems > fine to me. A proxy implementing toString, e.g., can make it work using these > traps just as well as via get+invoke, and without double lookup or > boolean-trap-smelling (id | func) parameterization of invoke.
In that case, why not just use [[Get]]+[[InvokeFunction]] in all cases (including obj.m(()) and not have the current [[Invoke]] at all. It allows the proxy handler to correctly intercede on all method invocations including conditional cones. Slogan: [[InvokeFunctiction]] is the new [[Call]]. (except that [[Call]] still needs to exist as an implementation mechanism and if we eliminate the current [[Invoke]] I would repurpose that name for what I'm currently calling [[InvokeFunction]]) Allen _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
