In a JavaScript call written as `a.b.c.method()`, which object becomes `this` inside `method`, and what rule decides that?

## The answer, and the rule behind it In `a.b.c.method()`, `this` inside `method` is `a.b.c`. The rule is **implicit binding**: when the thing being called is a property access, the receiver is the object that property was read from. The spec expresses this in terms of a *Reference* — evaluating `a.b.c.method` produces a Reference whose **base** is the value `a.b.c` and whose referenced name is `method`. The call then passes that base as `this`. Nothing else about how the base was reached is retained. ## Why the outer objects vanish Read the expression the way the engine does, left to right: 1. Evaluate `a` → an object. 2. Read property `b` from it → another object. `a` is now finished with. 3. Read property `c` from that → another object. `a.b` is now finished with. 4. Form the reference `<base = a.b.c, name = 'method'>` and call it. By step 4 the only object still in play is `a.b.c`. There is no chain of receivers, no parent pointer, and no way for `method` to walk back up to `a`. ```js const app = { name: 'app', db: { name: 'db', users: { name: 'users', who() { return this.name; } } } }; app.db.users.who(); // 'users' ``` ## The same rule in other syntactic shapes Implicit binding does not care which access syntax produced the base: ```js const key = 'users'; app.db[key].who(); // 'users' — bracket access, same base const rows = [{ id: 7, show() { return this.id; } }]; rows[0].show(); // 7 — the receiver is rows[0], not rows function pick() { return app.db.users; } pick().who(); // 'users' — the base is whatever the call returned ``` That last one is worth pausing on: the base does not have to be written as a variable path at all. Any expression that yields an object, followed by a dot and a call, supplies that object as the receiver. ## Where this bites in real code The common surprise is a namespaced configuration or service object: ```js const config = { env: 'prod', db: { host: 'db.internal', url() { return `${this.env}://${this.host}`; } // this.env is undefined } }; config.db.url(); // 'undefined://db.internal' ``` The author assumed `this` would be `config` because that is what they typed first. It is `config.db`, so `this.env` misses. There is no inheritance of receivers down a chain: each level's methods see only their own object (plus whatever it inherits through its prototype chain, which is a separate mechanism). The fix is to stop relying on `this` reaching further than it can — reference the outer object by name, or restructure so the data the method needs lives on the object the method hangs off. ## A second-order point: getters count too If `c` is an accessor property, its getter runs during step 3 and whatever it returns becomes the base: ```js const holder = { get current() { return { id: 42, read() { return this.id; } }; } }; holder.current.read(); // 42 — the base is the object the getter returned ``` A fresh object is produced on each access, so `holder.current.read` and a later `holder.current.read` are methods on two different receivers. ## What the interviewer is checking They want to hear "the object immediately before the dot", plus the reason: implicit binding uses the base of the property reference at the call site. Candidates who answer `a` are pattern-matching on the leftmost identifier, which is exactly the mistake that produces the `undefined://` style bug above.