In Ruby, what do instance_variable_get and instance_variable_set do, and why can instance_variables omit an attribute declared with attr_accessor?

## Instance variables belong to objects, not classes In Ruby, an instance variable such as `@total` is stored on an **individual object** and comes into existence the first time that object assigns it. A class does not declare a fixed set of fields. Two instances of the same class can therefore hold different sets of instance variables, depending on which code paths ran. ## The introspection methods | Call | Returns | Notes | |---|---|---| | `obj.instance_variables` | `Array` of symbols such as `[:@total]` | only variables assigned so far | | `obj.instance_variable_get(:@total)` | the value, or `nil` if unset | name must start with `@` | | `obj.instance_variable_set(:@total, 5)` | the assigned value, `5` | creates the variable if absent | | `obj.instance_variable_defined?(:@total)` | `true` / `false` | distinguishes unset from set to `nil` | | `obj.remove_instance_variable(:@total)` | the removed value | raises `NameError` if absent | All of them accept a `Symbol` or a `String` name. An invalid name, such as one without the `@`, raises `NameError` with a message saying it is not allowed as an instance variable name. ## Why attr_accessor does not show up `attr_accessor :total` generates two **methods**: a reader that returns `@total` and a writer that assigns it. It does not assign anything. The `instance_variables` documentation says it explicitly: *simply defining an accessor does not create the corresponding instance variable*. So: - right after `Invoice.new`, `instance_variables` may be `[]`; - after `invoice.total = 5`, it is `[:@total]`; - `invoice.total` before any assignment returns `nil`, because reading an unset instance variable returns `nil`. That is also why `instance_variable_get(:@total)` returning `nil` does not tell you whether the variable exists; `instance_variable_defined?` does. ## What bypassing means These methods are public and work from outside the object, so they **ignore the class's interface**: 1. A writer that validates or converts (`def total=(v) = @total = Integer(v)`) is skipped by `instance_variable_set`. 2. Private state is readable by any caller. 3. A typo such as `:@totl` silently creates a new variable instead of failing. The one guard that still applies is **freezing**: `instance_variable_set` on a frozen object raises `FrozenError`, like any other attempt to modify it. ## A generic copy with these methods The typical reason to use them is code that must work for **any** object without knowing its fields: ```ruby def snapshot(obj) obj.instance_variables.to_h do |name| [name.to_s.delete_prefix("@"), obj.instance_variable_get(name)] end end ``` This is useful and dangerous in equal measure: it copies whatever the object holds right now, including caches, credentials or half-built state, and it silently changes shape when a code path assigns a new variable. A snapshot taken before and after a method call can differ in its keys, not just its values. ## Where they belong - **Serializers and inspectors** that copy every field generically; `Kernel#inspect` itself shows instance variables. - **Debugging** in a console, to see an object's state without adding readers. - **Tests** that must set up hard-to-reach state, sparingly, since they couple the test to private names. - **Frameworks** that inject dependencies or restore objects from storage. In ordinary application code, a missing reader or writer is the design signal; reaching past it with `instance_variable_get` hides that. ## Mistakes to avoid - Omitting the `@` in the name. - Assuming `attr_accessor` creates the variable. - Treating a `nil` result as proof the variable is absent. - Using `instance_variable_set` to skip a setter's validation in production code. - Expecting every instance of a class to report the same `instance_variables`.