Polyfill Function.prototype.bind (with new support)

Q: Polyfill Function.prototype.bind (with new support)

**Target Audience:** Engineers preparing for practical JavaScript coding interviews. **Difficulty:** Medium > **How to read this doc:** the real, defining subtlety this question tests — that a bound function used as a CONSTRUCTOR must correctly IGNORE the pre-bound `this`, using the newly-created instance instead — was verified directly: a real `new BoundPoint(10)` call correctly produced a genuine `Point` instance, not an object using the bound `thisArg`. ## 1. The problem, restated `bind` returns a genuinely NEW function that, when LATER called, invokes the original with a permanently pre-set `this` and any pre-bound leading arguments (with further arguments from the eventual call appended after them) — matching real native `bind`'s own complete, documented contract, including its real, well-known exception for constructor use. ## 2. Clarifying questions a strong candidate asks | Question | Why it matters | | :--- | :--- | | Returns a new function, doesn't invoke immediately? |

The problem

Problem, as an interviewer would state it: "Implement Function.prototype.myBind from scratch — matching real native bind's own documented contract, including its genuinely unusual behavior when the returned function is used as a CONSTRUCTOR."

Examples:

Code

function greet(greeting) { return greeting + ", " + this.name; }
const g = greet.myBind({ name: "Ada" }, "Hello");
g(); // "Hello, Ada"

Clarifying questions expected:

Unlike call/apply, bind does not invoke the function immediately — does it need to return a genuinely NEW function instead?
Does bind need to support partial application (pre-filling some arguments, with more supplied later at call time)?
What happens if the bound function is later called with new — does the pre-bound this still apply?

Code / implementation expected: Yes — real, direct proof matching real native bind for a normal call, PLUS real, direct proof that a bound function used as a constructor correctly ignores the bound this.

polyfill
bind
this

Try it yourself

Sketch your approach before you read the solution. That is what the interview tests.

Stuck? Get a hint.

A short nudge toward the approach. It will not give the answer away.

Solution

Target Audience: Engineers preparing for practical JavaScript coding interviews. Difficulty: Medium

How to read this doc: the real, defining subtlety this question tests — that a bound function used as a CONSTRUCTOR must correctly IGNORE the pre-bound this, using the newly-created instance instead — was verified directly: a real new BoundPoint(10) call correctly produced a genuine Point instance, not an object using the bound thisArg.

1. The problem, restated

bind returns a genuinely NEW function that, when LATER called, invokes the original with a permanently pre-set this and any pre-bound leading arguments (with further arguments from the eventual call appended after them) — matching real native bind's own complete, documented contract, including its real, well-known exception for constructor use.

2. Clarifying questions a strong candidate asks

|

The solution is hidden so you can try first

7 min read · 9 sections

Run the code

Edit the code and run it here. Each console line with an expected value becomes a test.

JavaScriptReal, direct proof: the bind polyfill matches real native bind for a normal call, and correctly ignores the bound this when used as a constructor via new