Suppose a class defines `report` and includes a module that also defines `report`. The class’s method runs first. Calling `super` inside it runs the module’s version, then returns control to the class’s method. section 4.2.6
`super` calls the next definition of the current method along Ruby’s method-lookup path. That path can pass through prepended modules, the class, included modules, and superclasses; `super` does not necessarily mean “call the superclass.” section 4.2.5 section 4.2.6
The parentheses matter:
- `super` forwards the current method’s arguments and any code block to the next definition. section 4.2.6 section 13.2.4
- `super()` passes no arguments, even when the current method received some. section 4.2.6
Change only what a subclass needs
A `Bicycle` initializer sets wheels, seats, and gears. A `Tandem` initializer calls `super`, letting `Bicycle#initialize` receive the gears argument and set the defaults, then changes `@seats` to `2`. The subclass reuses the original setup rather than copying it. section 4.2.6
The same pattern works when handling missing methods. A custom `method_missing` can process recognized names and call `super` for everything else, leaving the next `method_missing` implementation to respond. To inspect that path, `object.method(:name).super_method` returns the next `Method`, or `nil` when no further definition exists. section 4.3.1 section 4.2.7
This object-specific `String#gsub!` wrapper uses `super` to run the original method, then returns `self` if that method returns `nil`. Extending one string avoids changing every string. section 13.2.4





