(changed subject to fork off discussion on function proxies) 2011/8/29 Allen Wirfs-Brock <[email protected]>
> On Aug 27, 2011, at 6:12 AM, Andreas Rossberg wrote: > > True, and actually, there are more issues with length & function > > proxies. I don't have my notes with me right now, but for example, it > > is not clear at all what length Function.prototype.bind should set > > when called on a function proxy. 0? 1? Should it try to get the length > > property from the proxy and subtract N? What if length is not defined > > on the proxy, or not a (natural) number? > > The ES5.1 spec. defines how how bind determines the length for the > function it creates based upon the length property of the target function. > I would expect the same rules would apply when the target is a function > proxy. I see two options here: a) either query the function proxy for its "length" property via its "get" trap, and convert the result using ToInteger, introducing a new error case if the conversion fails. b) or determine "length" based on the function proxy's call trap (which is presumably a non-proxy function. If it is a function proxy itself, recurse) The spec currently uses the wording: "Let L be the length property of Target ..." (ES5.1 section 15.3.4.5) If that is not equivalent to "Let L be the result of calling the [[Get]] internal method of Target with argument "length"", then option b) seems better. There is precedent for using the call trap as a substitute for the function proxy: Function.prototype.toString.call(aFunctionProxy) will also use the call trap's toString representation rather than trapping the handler. Cheers, Tom
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
