Function proxy length (Was: length property value for functions with parameter enhancements)

David Bruant david.bruant at labri.fr
Wed Aug 31 05:42:32 PDT 2011


Le 31/08/2011 13:24, Tom Van Cutsem a écrit :
> 2011/8/30 Brendan Eich <brendan at mozilla.com <mailto:brendan at mozilla.com>>
>
>     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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110831/ae3824af/attachment-0001.html>


More information about the es-discuss mailing list