Since Ruby 3.0, what RuntimeErrors do class variables raise when overtaken by an ancestor's definition or accessed from the top level?

## Background: how @@ lookup works A **class variable** (`@@name`) is looked up through the class tree: Ruby checks the current class, then its ancestors, including included modules. Assignment follows the same search, and only if no class in the chain has the variable does it create one in the current class. That design means the **same name can end up defined in two places** if they are created in the "wrong" order. ## Error 1: overtaken by an ancestor ```ruby class Shape end class Circle < Shape @@registry = [:circle] def self.registry = @@registry end Circle.registry # => [:circle] class Shape @@registry = [:shape] end Circle.registry # RuntimeError: class variable @@registry of Circle is overtaken by Shape ``` Step by step: 1. When Circle's body ran, no ancestor had `@@registry`, so it was created **in Circle**. 2. When Shape was reopened, Shape had no `@@registry` of its own and nothing above it did either, so a **second** variable was created in Shape. 3. On the next read, Ruby finds the name in both Circle and Shape. Since Ruby 3.0 it refuses to guess and raises `RuntimeError`. The same error appears when a **module** that defines `@@registry` is included into a class that already has its own, with the message naming the module. Before Ruby 3.0 this situation produced only a warning, and only in verbose mode, so the conflict could sit unnoticed. Typical real-world causes: - a base class file loaded **after** a subclass file, for example after changing `require` order or autoload behaviour; - a shared module that grew a `@@` variable with a common name; - a monkey-patch that assigns `@@something` in a parent class. The fix is structural: define the variable **once**, in the class that should own it, before subclasses use it, or better, replace it with class-level instance variables so each class owns its own. ## Error 2: access from the top level ```ruby # at the top of a script, outside any class @@count = 0 # RuntimeError: class variable access from toplevel ``` Top-level code runs with no enclosing class or module definition, so there is no class that could own a class variable. Since Ruby 3.0, reading or writing `@@count` there raises `RuntimeError`. A few details: - It applies to **both** reads and writes. - `defined?(@@count)` at top level is allowed; it does not raise and returns `nil`. - Code inside a method or block that was **defined at top level** is still top-level code for this purpose. ## Finding and fixing an overtaking conflict The error message names both parties: the class you read from and the class or module that also defines the name. To confirm, ask each one for the class variables it defines itself; `Module#class_variables(false)` leaves out inherited ones: ```ruby Circle.class_variables(false) # => [:@@registry] Shape.class_variables(false) # => [:@@registry] ``` Two entries for one name is the conflict. Then: 1. Decide which class should own the value, normally the base class. 2. Make sure that class assigns it before any subclass or module touches it, or remove the assignment from the subclass. 3. Better still, replace the variable with class-level instance variables read through `def self.` methods, so no two classes can compete for one name. ## Summary | Situation | Ruby 3.0 and later (4.0 included) | |---|---| | Same `@@name` in a class and in an ancestor or included module | `RuntimeError`, "... is overtaken by ..." | | `@@name` read or written at top level | `RuntimeError`, "class variable access from toplevel" | | `defined?(@@name)` at top level | `nil`, no error | | Reading a `@@name` defined nowhere | `NameError`, uninitialized class variable | ## Why interviewers ask it It is a quick check of whether a candidate has migrated real code across the 3.0 boundary and understands why class variables are fragile: their meaning depends on **definition order** across files. A candidate who can explain the overtaking error has, in effect, explained why many Ruby teams avoid `@@` entirely.