Discuss
  • Function proxies without explicit construct trap

Function proxies without explicit construct trap

# Andreas Rossberg (14 years ago)

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 hg.ecmascript.org/tests/harmony.

Any ideas?

# Tom Van Cutsem (14 years ago)

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 <rossberg at google.com>

# Brendan Eich (14 years ago)

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.

# Tom Van Cutsem (14 years ago)

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.