In Ruby, why does `rows.inject({}) { |h, r| h[r.bib] = r.secs }` fail, and how does each_with_object avoid it?

## The task A marathon results import has one row per runner, and the next step needs a lookup **Hash** from bib number to finishing time in seconds. Both `inject` and `each_with_object` can build it, but they pass their accumulator in different ways, and that difference is the whole question. ## How `inject` threads its memo `inject` (also called `reduce`) keeps an **accumulator**, often called the memo. On each element it calls the block with `memo, element`, and the block's **return value becomes the memo** for the next element. The final memo is the result. That is exactly right for arithmetic, where the block naturally returns the new value. It goes wrong when the block's last expression is an assignment: ```ruby rows.inject({}) { |h, r| h[r.bib] = r.secs } ``` In Ruby an element assignment `h[k] = v` **evaluates to `v`**, not to the hash. So: 1. First row: `h` is `{}`, the block stores one entry and returns `r.secs`, an Integer. 2. Second row: `h` is now that Integer, and `Integer` has no `[]=` method, so Ruby raises `NoMethodError`. 3. With exactly **one** row there is no second call, and the method returns a bare number instead of a hash. That is the worse outcome, because nothing fails until much later. The inject-shaped fix is to return the hash explicitly: `{ |h, r| h[r.bib] = r.secs; h }`. Using `h.merge(r.bib => r.secs)` also works but builds a new hash on every step. ## How `each_with_object` threads its memo `each_with_object(obj)` passes the **same object** to every call and **ignores** the block's return value. When the walk ends it returns `obj`. The rdoc signature in Ruby's `enum.c` shows it: `each_with_object(object) { |(*args), memo_object| ... } -> object`. ```ruby rows.each_with_object({}) { |r, h| h[r.bib] = r.secs } ``` No trailing `h` is needed, and a single row, or none, still returns a hash. ## Side by side | | `inject(memo)` | `each_with_object(memo)` | |---|---|---| | Block parameters | `\|memo, element\|` | `\|element, memo\|` | | Next memo is | the block's return value | the same object again | | Returns | the last memo | the object you passed in | | Works with immutable memo | yes (numbers, frozen strings) | no, rebinding is lost | | Natural use | combining values into one value | filling a hash or array | ## The two traps around `each_with_object` - **Parameter order.** The element comes first and the memo second, the reverse of `inject`. Swapping them in the block does not raise; it just stores rows under the wrong keys. - **Immutable memos.** `each_with_object(0) { |r, sum| sum += r.secs }` returns `0`. The `+=` rebinds the block-local variable `sum` to a new Integer; the object held by `each_with_object` never changes. Integers are immutable, so there is nothing to mutate. Totals belong to `inject`, `sum` or similar. ## Choosing between them A practical rule reviewers use: - If the accumulator is a **value** you replace (a number, a frozen string, a new record each step), use `inject`. - If the accumulator is a **container** you fill in place (a hash, an array, a set), use `each_with_object`. - If the shape is a common one, such as pairs into a hash, grouping, or counting, a dedicated method usually reads better than either. `Enumerator#with_object` is the same operation reached through an enumerator, so `rows.each_with_index.with_object({})` can combine an index with a memo. ## Other memo types The same distinction applies to arrays and sets, not just hashes: - `rows.each_with_object([]) { |r, acc| acc << r.bib if r.secs < 10_800 }` fills an array in place. Written with `inject`, the same block would hand `nil` on as the next memo whenever the `if` modifier is false, because a failed modifier `if` evaluates to `nil`; the bug appears only for some rows, which makes it easy to miss. - `rows.each_with_object(Set.new) { |r, seen| seen << r.country }` collects distinct values; `Set` is a core class in Ruby 4.0, so no `require` is needed. - A **frozen** memo, such as an array created with `.freeze`, raises `FrozenError` as soon as the block tries to append to it, because the method never replaces the object. In every case the question to ask is the same: does the block **change the object** it was given, or does it **produce a new one**? Change means `each_with_object`; produce means `inject`. ## What interviewers listen for The strong answer names the mechanism, not just the fix: inject's next memo is the block's value, assignment returns the assigned value, and each_with_object sidesteps that by returning the object it was given. Then mention the swapped parameter order and the immutable-memo trap, which show you have actually used it.