Le 31/08/2011 13:24, Tom Van Cutsem a écrit :
2011/8/30 Brendan Eich <[email protected] <mailto:[email protected]>>
On Aug 30, 2011, at 2:16 PM, David Bruant wrote:
Actually that's what current function proxies do by default (no
.prototype unless otherwise specified). My suggestion is to put a
.prototype by default with keeping the option to opt-out (same
with .length, etc.)
Right, of course function proxies have to trap in order to emulate
.prototype and other properties.
Indeed, that was our intent: fproxy.prototype and fproxy.length are
determined by the handler via the "get" trap.
This should work fine for fproxy.prototype (and it is actually
consulted when evaluating |obj instanceof fproxy|.)
For fproxy.length, the handler object can only return the call trap's
length if it has a reference to the call trap, which as David points
out, in the general case it does not. OTOH, typically a function proxy
will wrap some other target function f, in which case the handler
would simply return f.length, so I don't know whether this issue is
such a big deal.
True. Still, a handler needs an access to the callTrap in order to
retrieve its length in the general case. And with the current API, it
may be impossible for an already created handler (not one created
through a factory) to access to the callTrap, making impossible to
access its .length and .prototype
I agree that the typical case is to wrap, but is it a sufficient reason
for people not wrapping to not be able to properly emulate function.length?
If one wraps an existing function f using the default
ForwardingHandler like so:
var fproxy = Proxy.createFunction(new ForwardingHandler(f), f);
Alternatively, i suggested earlier this summer [1] to put callTrap and
constructTrap as part of the handler. This which would solve the problem
of a handler having access to the callTrap ("this.call" from any other
trap) and would also solve the question "what if handler.call.length !==
handler.construct.length?" which would be left to the author discretion.
David
[1] https://mail.mozilla.org/pipermail/es-discuss/2011-August/016247.html
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
