Function proxies without explicit construct trap

Brendan Eich brendan at mozilla.com
Sun Nov 13 08:42:06 PST 2011


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 <rossberg at 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 at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
> 
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20111113/e1b4ca16/attachment-0001.html>


More information about the es-discuss mailing list