A Ruby Hash keyed by Point objects stops finding an entry after that point's x is changed in place; why, and how do you prevent or repair it?

## Why the entry disappears A `Hash` stores each entry in a position derived from the key's **`hash` value at insertion time**. It does not watch the key object afterwards. If the key is mutated in a way that changes its `hash`, the stored position is now wrong: ```ruby Point = Struct.new(:x, :y) # mutable: has x= and y= home = Point.new(1, 2) visits = {home => 3} home.x = 9 # hash value changes visits[home] # => nil visits.key?(home) # => false visits.keys.include?(home) # => true visits.rehash visits[home] # => 3 ``` What each line shows: - `visits[home]` computes the **new** hash, looks where that hash points, and finds nothing. - `key?` does the same lookup, so it is also false. - `keys.include?` builds an Array of keys and compares them with `==`, which ignores hashing, so it finds the very same object. The core documentation describes exactly this under "Modifying an Active Hash Key", using Array keys, and the same applies to `Set` and to anything else built on `eql?` and `hash`. ## Repairing: `Hash#rehash` `Hash#rehash` recomputes the position of every key from its current `hash` and returns the hash. Two cautions: 1. Calling it **while iterating** over the same hash raises `RuntimeError` (rehash during iteration). 2. If the mutation made two keys equal, rehashing merges them and one entry wins, so data can disappear. For a `Set`, the equivalent is `Set#reset`, which reindexes and deduplicates the elements after they were modified. Rehashing is a repair, not a design: it only helps if you know every place that mutates keys. ## Preventing it | Approach | How it helps | |---|---| | `Data.define(:x, :y)` | instances are frozen and have no setters; equality and hash are generated | | `freeze` in `initialize` | any later write raises `FrozenError` instead of corrupting the index | | No writer methods on key classes | removes the easy way to mutate a key | | `compare_by_identity` on the Hash | keys match by identity only, so field changes do not matter | | Keep a stable id as the key | store `point.id` or a frozen tuple instead of the live object | Be aware that freezing is **shallow**. A `Data` instance with an Array member is frozen, but the Array inside it is not; pushing into that Array changes the member's `hash` and therefore the key's. Keys should be built from values that are themselves immutable. ## Why String keys are safe `Hash#[]=` treats String keys specially: an unfrozen String is replaced by a **duplicated and frozen copy**, so later changes to your original string cannot affect the stored key. No other class gets this treatment; Arrays, Structs and your own classes are stored as the very object you passed. ## Diagnosing it in production The symptom is a lookup that returns `nil` or a default for a key you can see when you print the hash. When that happens: 1. Check whether the key's class has setters or mutable fields used by `hash`. 2. Confirm it on a copy: `h.dup.rehash[key]`. If the lookup succeeds after rehashing, a key's hash changed after insertion. 3. Look for code paths that modify objects after they were inserted, including helper methods that call `<<` on an Array member. ## Why interviewers ask it It is a senior question because the bug appears far from its cause and the Hash is not "broken" in any visible way. A strong candidate explains the mechanism, knows `rehash` exists and its caveats, and fixes the design with immutable keys rather than sprinkling `rehash` calls.