5 The default object (self), scope, and visibility
Ruby programming is strongly shaped by context: the meaning of names changes depending on where code appears, what object is currently “self,” and what kind of scope you are in. This chapter explains how to orient yourself in that shifting landscape so you can predict whether an identifier refers to a local variable, a method call, a constant, or an object’s state. The central idea is that Ruby always has a current default object, and understanding which object that is at any moment makes the rest of the language much easier to reason about.
The first major theme is self, the current object. At the top level, self is the special object main; inside a class or module definition, self becomes the class or module object itself; inside an instance method, self becomes the receiver that invoked the method; and inside a singleton or class method, self is the specific object whose method it is. This matters because self is the default receiver for dotless method calls, and it also determines ownership of instance variables. The chapter emphasizes that instance variables belong to the current self, so the same variable name can refer to completely different state depending on whether code is running in a class body, an instance method, or a class method.
The second major theme is scope, especially for local variables, globals, constants, and class variables. Local scope changes whenever you enter a class, module, or method definition, while global variables remain visible everywhere. Constants follow nesting and lookup rules, so the same constant name can resolve differently depending on location, and a leading :: forces lookup from the top level. Class variables, meanwhile, are shared across a class hierarchy, which makes them convenient for shared state but also risky because they can leak across subclasses in surprising ways. The chapter closes by connecting these ideas to method access: private methods require an implicit receiver, protected methods allow controlled access among related objects, and top-level methods are simply private methods added to Object, which is why bareword calls like puts work throughout Ruby code.
The determination of self in different contexts.
Schematic view of local scopes at the top level, the class-definition level, and the method-definition level.
Summary
- To understand a program in depth—and to write well-organized, robust programs—you need to know how to detect where the various local scopes begin and end; how constants, instance variables, and other identifiers are resolved; and how to evaluate the impact of the ever-shifting role of self.
- At any given point in program execution, one and only one object is “self”. But the role of self can rotate among many objects.
- self is the default receiver for method calls with no explicit receiver.
- All instance variables belong to self, whatever object self may be at the time the instance variable is evaluated—including when self is a class or module object.
- Classes are objects too!
- Local, global, and class variables all have their own scope and visibility rules.
- It’s important to know how to look up and resolve constants.
- Ruby’s method-access levels are public, private, and protected.
- Method definitions written at the top level of your script, rather than inside a class or module definition, become private instance methods of Kernel, and from Kernel, through the Object class, they become available as private methods to all objects (for example, you can call them “bareword”-style no matter what object is self).
FAQ
What is `self` in Ruby, and why is it important?
`self` is the current or default object in Ruby. It matters because it determines which object receives bareword method calls, where instance variables belong, and how method access rules are applied.
How does Ruby decide which object is `self`?
Ruby changes `self` based on context. At the top level, `self` is `main`; inside a class or module definition, it becomes that class or module object; inside an instance method, it becomes the object that received the message; and inside a singleton or class method, it becomes the object owning that method.
What is the top-level `self` object in Ruby?
The top-level `self` is a special object called `main`. It exists so Ruby always has a current object, even when code is written outside any class or module definition.
What is a bareword method call in Ruby?
A bareword method call is a method invocation without an explicit receiver, such as `talk` instead of `self.talk`. Ruby treats it as a call to `self` if no local variable with the same name takes precedence.
When do you need to write `self.` explicitly in a method call?
You must use `self.` when calling setter methods like `self.name = "Ruby"` because `name = "Ruby"` is always interpreted as local-variable assignment. You may also use `self.` to make a method call unambiguous when a local variable has the same name as the method.
How do local variables behave across classes, modules, and methods?
Local variables are scoped to the current local scope. Entering a class, module, or method definition starts a new local scope, so a local variable with the same name in each scope is a different variable.
How are instance variables related to `self`?
Instance variables belong to whatever object is `self` at the moment the code runs. That means `@v` inside an instance method belongs to the receiver object, while `@v` inside a class method belongs to the class object itself.
How do constants get resolved in Ruby?
Constants are looked up relative to where the code appears, following the nesting of classes and modules. You can force an absolute lookup from the top level by starting the constant name with `::`.
Why are class variables often considered tricky in Ruby?
Class variables (`@@var`) are shared across a class hierarchy, not just within one class. That means subclasses can see and change the same variable, which can make state harder to isolate and reason about.
How do private and protected methods differ in Ruby?
Private methods can only be called without an explicit receiver, and effectively only on `self`. Protected methods are a bit more flexible: they can be called with an explicit receiver, but only when `self` is of the same class or a related class in the inheritance chain.
The Well-Grounded Rubyist, Fourth Edition ebook for free
