A team moved a per-call helper's placeholder up onto the connection declaration - why must callers now hold several connections?

## What hoisting actually changes Moving a placeholder from an operation's signature up to the declaration looks like tidying: one name instead of several, less noise on each member. What it really does is **move the moment of commitment**. An operation-level name is chosen when the call happens; a declaration-level name is chosen when the object is built. Everything else follows from that one shift. In the chat-client setting: a connection exposes an encode-and-queue helper, originally written with its own placeholder so any value that has an encoder can be queued. Hoisted onto the connection, the helper's name becomes the connection's name, so the connection is now a *connection for one kind of value*. ## The bill the caller pays 1. **One instance per type.** A caller with three message kinds needs three connections, because an instance fixes the name once. The object's identity has been tied to a type it never needed. 2. **Lifecycle multiplied.** Connections are not free objects: each has setup, teardown, buffers, retry state. Three of them means three of each, and three things to keep consistent. 3. **Shared state is split.** Anything the connection accumulated for all traffic - sequence numbers, a backlog, statistics - now lives separately in each instance and no longer sees the whole picture. 4. **Passing it around gets harder.** Code that used to accept *a connection* now has to name the type too, and that requirement spreads outward through every signature that holds one. 5. **Callers who never use the helper still pay.** They must supply a type argument at construction for a member they never touch. ## Reading the smell in a signature The diagnostic is a counting exercise, not an opinion: | Evidence | Reading | |---|---| | Most members never mention the name | It does not describe the object | | No stored state is typed by it | Nothing has to survive between calls | | Callers build one instance per type | The commitment landed in the wrong place | | One operation uses it, once, in its own signature | It was per-call work all along | The inverse smell exists too, and it is worth naming so the rule does not get applied blindly: if every member mentions the name, stored state is typed by it, and callers reuse one instance across many calls, then the declaration is exactly where it belongs and pushing it down would destroy the agreement between members. ## Undoing it The repair is to give the operation its placeholder back and leave the declaration parameterized only by what it genuinely stores - or, where the connection stores nothing of the kind, not parameterized at all. Two things make this harder than it sounds: - **It is a breaking change at every call site**, because construction stops taking a type argument and the operation starts choosing one. There is no way to do it gradually within one signature. - **It can expose a second, real problem**: sometimes the hoist happened because something *was* being stored per type, and pushing the name down forces that state to be typed honestly instead. ## The judgment to demonstrate The interviewer is checking whether you read a declaration site as an **API commitment** rather than as syntax. The question to ask out loud is: *how many instances will a caller with n types end up holding?* If the answer is n and the object is expensive, the placeholder is in the wrong place. If the answer is one because every call at that instance genuinely is about the same type, it is in the right one. A related trap is to fix the instance explosion by widening the hoisted name to some universal type and narrowing inside the operations. That restores the single instance and throws away the checking that motivated parameterizing in the first place - a strictly worse position than either honest choice, and the thing to argue against in review. Languages differ in how much ceremony each site costs to write, which is part of why the wrong hoist happens: the tidier-looking declaration is sometimes the more expensive contract. The scoping consequence, though, is the same everywhere - a name on a declaration lives as long as an instance, so it prices every instance the caller has to make.