Re: Function proxies without explicit construct trap
Earlier I wrote: All good points, and I don't recall any of them being intentional. Your points seem to suggest changing the semantics such that calling new fproxy() on a function proxy without a construct trap should perhaps just simply throw a TypeError. Looking at the problem again, the way in which [[Construct]] for function proxies should have been specced is that if no constructTrap is present, the function proxy should default to the built-in [[Construct]] algorithm for Functions (ES5 section 13.2.2, with F now being a function proxy), rather than calling the callTrap's [[Construct]] method. This will trigger the get trap of the function proxy, to lookup the prototype property, and the new instance will inherit from that. Cheers, Tom ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Function proxies without explicit construct trap
Hi Andreas, All good points, and I don't recall any of them being intentional. Your points seem to suggest changing the semantics such that calling new fproxy() on a function proxy without a construct trap should perhaps just simply throw a TypeError. Now, in the direct proxies design, a missing [[Construct]] trap could simply forward to the [[Construct]] internal method of the target (not the call trap!). That would be cleaner (direct proxies no longer feature a virtual prototype, they reuse the target's prototype anyway) and seems to be where we were trying to take the current [[Construct]] trap default behavior. Unfortunately, since current proxies don't have a target, we chose the call trap, which isn't quite the right choice. Regarding the test case: I think it is broken (IMHO, it expects the most intuitive result. Since the current semantics don't align with that intuition, that's a good enough signal for me that we should probably change the behavior to throw a TypeError). I'll update the test case. Cheers, Tom 2011/11/10 Andreas Rossberg rossb...@google.com I think the specification of [[Construct]] for function proxies may not currently be doing what it is intended to do. If the proxy does not have a construct trap, the method simply delegates to the [[Construct]] method of the call trap. AFAICS, that has two consequences: 1. The prototype is taken from the call trap, not from the proxy. 2. If the trap returns a primitive value, that will be ignored and replaced with a freshly allocated object, as usual. It is not clear to me whether either was intended, but the former seems surprising, and the latter is inconsistent with the behaviour expected by the construct-primitive test case from http://hg.ecmascript.org/tests/harmony/. Any ideas? /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Function proxies without explicit construct trap
On Nov 13, 2011, at 7:51 AM, Tom Van Cutsem wrote: Hi Andreas, All good points, and I don't recall any of them being intentional. Your points seem to suggest changing the semantics such that calling new fproxy() on a function proxy without a construct trap should perhaps just simply throw a TypeError. I recall a bit of intention: we wanted to default to calling the call trap with a new object bound to |this|, as is done for user-defined functions. /be Now, in the direct proxies design, a missing [[Construct]] trap could simply forward to the [[Construct]] internal method of the target (not the call trap!). That would be cleaner (direct proxies no longer feature a virtual prototype, they reuse the target's prototype anyway) and seems to be where we were trying to take the current [[Construct]] trap default behavior. Unfortunately, since current proxies don't have a target, we chose the call trap, which isn't quite the right choice. Regarding the test case: I think it is broken (IMHO, it expects the most intuitive result. Since the current semantics don't align with that intuition, that's a good enough signal for me that we should probably change the behavior to throw a TypeError). I'll update the test case. Cheers, Tom 2011/11/10 Andreas Rossberg rossb...@google.com I think the specification of [[Construct]] for function proxies may not currently be doing what it is intended to do. If the proxy does not have a construct trap, the method simply delegates to the [[Construct]] method of the call trap. AFAICS, that has two consequences: 1. The prototype is taken from the call trap, not from the proxy. 2. If the trap returns a primitive value, that will be ignored and replaced with a freshly allocated object, as usual. It is not clear to me whether either was intended, but the former seems surprising, and the latter is inconsistent with the behaviour expected by the construct-primitive test case from http://hg.ecmascript.org/tests/harmony/. Any ideas? /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Function proxies without explicit construct trap
I think the specification of [[Construct]] for function proxies may not currently be doing what it is intended to do. If the proxy does not have a construct trap, the method simply delegates to the [[Construct]] method of the call trap. AFAICS, that has two consequences: 1. The prototype is taken from the call trap, not from the proxy. 2. If the trap returns a primitive value, that will be ignored and replaced with a freshly allocated object, as usual. It is not clear to me whether either was intended, but the former seems surprising, and the latter is inconsistent with the behaviour expected by the construct-primitive test case from http://hg.ecmascript.org/tests/harmony/. Any ideas? /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
