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

Reply via email to