New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GetFunctionRealm argument #814

Open
jmdyck opened this Issue Feb 11, 2017 · 2 comments

Comments

Projects
None yet
2 participants
@jmdyck
Collaborator

jmdyck commented Feb 11, 2017

The abstract operation GetFunctionRealm(_obj_) asserts that _obj_ is a callable object. However, consider the steps later in the definition:

  1. Let _proxyTarget_ be _obj_.[[ProxyTarget]].
  1. Return ? GetFunctionRealm(_proxyTarget_).

I don't think there's a guarantee that _obj_.[[ProxyTarget]] is callable, in which case the recursive call would fail the assertion.

@ljharb

This comment has been minimized.

Show comment
Hide comment
@ljharb

ljharb Feb 11, 2017

Member

How could a proxy be callable, but its target not be?

Member

ljharb commented Feb 11, 2017

How could a proxy be callable, but its target not be?

@jmdyck

This comment has been minimized.

Show comment
Hide comment
@jmdyck

jmdyck Feb 11, 2017

Collaborator

Ah, ProxyCreate() will make the proxy callable only if the target is.

But that seems unnecessarily restrictive: if the handler has an "apply" method, why does the target need to be callable?

Collaborator

jmdyck commented Feb 11, 2017

Ah, ProxyCreate() will make the proxy callable only if the target is.

But that seems unnecessarily restrictive: if the handler has an "apply" method, why does the target need to be callable?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment