hax / hax/proposal-function-this

Skepticism

Open
#4 1 comment 0 reactions 0 assignees View on GitHub
Dominant language
JavaScript
Stars
4
Forks
1
PR merge metrics
No merged PRs in 30d

Description

AFAIU `isThisArgumentExpected` is whether both of the following are true:
1. Does `this` appear syntactically in the body text of the function?
1. And does `this` bind the receiver?

When both are true, the motivation as I understand is to use that as a proxy metric for whether the programmer intended the function to have a non-`undefined` receiver when called, so errors can be thrown earlier.

I'm pretty skeptical that this is a good solution:

- Condition 1 above only makes sense for user functions. For native platform functions, how do you expect this method to answer? Do all native platforms need to now build in whether or not they expect to work with a non-`undefined` recevier? That seems infeasible. Similar question for proxies.
- Using this outside of userland frameworks requires monkeypatching platform APIs, like `setTimeout`. This adoption path is a nonstarter and doesn't make this proposal very useful IMO.
- The actual information you want is one about programmer intent. I admit that conditional uses of `this` are rare in first party code, but I've seen my share of adapter functions that need to thread `this` to preserve semantics while forwarding. How would they forward this information through?
- It feels like an ad-hoc reified predicate for a static property you want from a type system. It feels off given the rest of the JS function API.

All of this points to that this space is best solved via tooling.

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.