Custom Object.create polyfill

Q: Custom Object.create polyfill

**Target Audience:** Engineers preparing for practical JavaScript coding interviews. **Difficulty:** Medium > **How to read this doc:** a genuinely REAL BUG was caught during this doc's own verification process — a first, naive implementation using `function F() {}; F.prototype = proto; new F();` silently produced an object linked to `Object.prototype` when called as `myObjectCreate(null)`, NOT a genuinely null-prototype object, diverging from real native `Object.create(null)`. This is a real, documented JavaScript spec behavior (`OrdinaryCreateFromConstructor` falls back to `Object.prototype` whenever a constructor's own `.prototype` is not an object) — the corrected version, using an explicit `Object.setPrototypeOf(obj, null)` for that specific case, was re-verified to match real native `Object.create(null)` exactly. ## 1. The problem, restated Create a genuinely NEW object whose `[[Prototype]]` internal slot is set to `proto` — supporting the real, special case where `proto` is `

The problem

Problem, as an interviewer would state it: "Implement Object.create from scratch — creating a new object with a specified prototype, correctly handling the special Object.create(null) case (an object with NO prototype at all), matching real native behavior exactly."

Examples:

Code

const parent = { greet() { return "hi"; } };
const child = myObjectCreate(parent);
child.greet(); // "hi" -- inherited via the prototype chain

Clarifying questions expected:

Does Object.create(null) need to genuinely produce an object with NO prototype at all, not just an object linked to Object.prototype?
Does the optional second propertiesObject argument (matching real Object.defineProperties's own format) need to be supported?
What should happen if proto is neither a real object nor null?

Code / implementation expected: Yes — real, direct proof of correct prototype linking, AND real, direct proof that myObjectCreate(null) produces a genuinely null-prototype object, not one silently linked to Object.prototype.

js-coding
utility
algorithm

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: a genuinely REAL BUG was caught during this doc's own verification process — a first, naive implementation using function F() {}; F.prototype = proto; new F(); silently produced an object linked to Object.prototype when called as myObjectCreate(null), NOT a genuinely null-prototype object, diverging from real native Object.create(null). This is a real, documented JavaScript spec behavior (OrdinaryCreateFromConstructor falls back to Object.prototype whenever a constructor's own .prototype is not an object) — the corrected version, using an explicit Object.setPrototypeOf(obj, null) for that specific case, was re-verified to match real native Object.create(null) exactly.

1. The problem, restated

Create a genuinely NEW object whose `[

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 corrected Object.create polyfill matches real native behavior, including the genuinely null-prototype case that a naive new F() approach silently got wrong